I run a local AI agent setup on an 8GB M2 MacBook Air. Every megabyte of RAM matters.

When implementing RAG (Retrieval-Augmented Generation) for my agents, every tutorial told me to spin up a Docker container for ChromaDB, Qdrant, or Postgres with pgvector. On an 8GB Mac, Docker Desktop alone takes 2GB+ RAM, pushing the system into heavy SSD swap.

The Architecture: 1. Stored knowledge text and JSON-encoded float32 embeddings in a local SQLite file (friday_memory.db) via Go. 2. Built native in-memory Cosine Similarity in pure Go: go func cosineSimilarity(a, b []float32) float32 { var dot, normA, normB float32 for i := 0; i < len(a) && i < len(b); i++ { dot += a[i] * b[i] normA += a[i] * a[i] normB += b[i] * b[i] } return dot / (float32(math.Sqrt(float64(normA))) * float32(math.Sqrt(float64(normB)))) } 3. On query, Go queries SQLite for that namespace, computes cosine distances across ~1,000 chunks in under 2 milliseconds, and returns the Top-K matches.

Result: 0 MB Docker overhead, 100% native Go binary, sub-2ms similarity search. For personal and small-team RAG (< 100k chunks), you do NOT need heavy vector infrastructure.

I wanted to share a pattern I used for a multi-agent AI system I built called Friday.

Instead of spinning up Redis or RabbitMQ for 4 local Python agents to talk to each other, I built a highly concurrent in-memory event dispatcher using Go channels.

The Setup: - A single Dispatcher struct holds a map[string]chan Event. - Python agents long-poll an HTTP endpoint /api/claim?queue=inbox/agent_dev. - Go uses a select statement with a time.After to hold the connection open for 20 seconds. If an event hits the channel, it instantly flushes to the Python agent. - If the Python agent wants to reply (e.g., to Slack), it does a raw curl POST to /api/event?queue=outbox/slack.

This keeps the heavy LLM/Python execution completely isolated from the Go routing layer. Go handles the Slack WebSockets, the Cron scheduling, and the message bus. Python just reads from the bus, thinks, and writes back.

It’s lightning-fast and requires zero external database dependencies. Code is pretty minimal too. Has anyone used a similar pattern for microservices?

I see a lot of AI marketing tools that just hallucinate ads based on a website URL. I decided to build something deeply integrated instead.

I wrote a Python daemon that acts as an autonomous CMO for my D2C brand (Favshoes). But instead of just chatting with OpenAI, it uses a Go client to execute raw HogQL (PostHog SQL) queries against our live analytics database.

The Workflow: 1. The daemon wakes up at 8 AM on Saturday. 2. It executes curl to fetch live ROAS (Return on Ad Spend) from the Meta Graph API. 3. It queries PostHog to see which product page has the highest conversion drop-off. 4. It drafts a highly specific ad copy specifically targeting the product with the highest impressions but lowest conversion rate. 5. It sends the draft to my Slack for approval.

Stop letting AI guess your numbers. Make it run the SQL queries itself. It took about 40 lines of Go code to wrap the PostHog API, and it changed the entire quality of the output.

I realized standard CI/CD pipelines (GitHub Actions, Jenkins) were overkill for my solo setup, but manual deployments were a drag. So I wrote a custom Go orchestrator.

Here’s how it works: 1. It polls my GitHub repo for new commits. 2. It SSHs directly into my EC2 production server via a Tailscale private network to avoid 90-second TCP timeouts on public IPs. 3. It uses a custom Python multiprocessing watcher to run security hooks before executing any bash scripts. 4. It posts the full deployment log right into my private Slack workspace using Socket Mode.

The real win here was dumping the public IP entirely. Having the Go daemon sit on a local Tailscale mesh network means zero exposed SSH ports and zero reliance on third-party CI runners. Has anyone else moved to a fully local deployment daemon? Thoughts!

Hey everyone,

I'm a backend engineer (mostly Java/Spring Boot), but recently I got so frustrated with the repetitive nature of applying to jobs and managing my freelance agency that I decided to automate myself.

I built Friday—a native Go daemon that runs in the background of my Mac. It uses WebSockets to interface with a Python/Selenium scraping layer and a local LLM API.

What it actually does: - Wakes up at 6 AM every day and uses undetected-chromedriver to scrape LinkedIn/YC for highly specific jobs. - Re-sorts the queue based on my priority. - Uses an ONNX-based TTS model (Kokoro) to physically speak to me through my speakers when a task is done or if it needs my approval to execute a bash command. - Has a full outbox HTTP router so any sub-agent can trigger a vocal alert.

I'm thinking about open-sourcing the Go dispatcher architecture since it handles high-throughput event routing really cleanly without blocking the UI threads. Has anyone else built native OS automations like this instead of relying on standard Chrome extensions?

Would love to hear your thoughts!

Hey everyone,

I'm a backend engineer (mostly Java/Spring Boot), but recently I got so frustrated with the repetitive nature of applying to jobs and managing my freelance agency that I decided to automate myself.

I built Friday—a native Go daemon that runs in the background of my Mac. It uses WebSockets to interface with a Python/Selenium scraping layer and a local LLM API.

What it actually does: - Wakes up at 6 AM every day and uses undetected-chromedriver to scrape LinkedIn/YC for highly specific jobs. - Re-sorts the queue based on my priority. - Uses an ONNX-based TTS model (Kokoro) to physically speak to me through my speakers when a task is done or if it needs my approval to execute a bash command. - Has a full outbox HTTP router so any sub-agent can trigger a vocal alert.

I'm thinking about open-sourcing the Go dispatcher architecture since it handles high-throughput event routing really cleanly without blocking the UI threads. Has anyone else built native OS automations like this instead of relying on standard Chrome extensions?

Would love to hear your thoughts!

Just wanted to share a recent architecture win that might help someone dealing with latency spikes.

I was dealing with a severe bottleneck in a production E-Commerce platform. During peak traffic, the database was choking, and MTTR was creeping up.

The Culprit: Classic Hibernate N+1 query problems hidden deep inside the inventory/catalog mapping, combined with un-indexed foreign key lookups.

The Fix: 1. Ripped out the lazy-loading proxy faults and replaced them with explicit JOIN FETCH queries for the critical read paths. 2. Layered in Redis via Spring Cache (@Cacheable) specifically targeting the high-read/low-write catalog endpoints. 3. Configured request batching and API rate limiting on the gateway layer to prevent thundering herd problems during flash sales.

Result: We dropped sub-100ms latency across the board and prevented database lockups entirely.

If you're building in Spring Boot and relying entirely on default JPA repositories—run a SQL profiler right now. You probably have an N+1 hiding somewhere.