Akshay 🚀 (@akshay_pachaar)

How to build a 1-person AI company that: - Runs locally - 100% open-source - No human employees, all agents - Real-time collaboration via email Multi-agent orchestration is not new. Plenty of frameworks already let agents hand off tasks, run in parallel, and talk to each other. So the interesting question is not whether agents can collaborate. It is what structure you use to make them collaborate. The common approach is to wire a graph of nodes and edges and reason about the plumbing yourself. It works, but you are learning a new abstraction just to describe who does what. There is a coordination structure we have trusted for a hundred years already: an organization. Every company runs the same way. People have roles, roles have reporting lines, and work moves up and down that chart without anyone relaying each message by hand. Map that onto agents and the whole thing gets intuitive. You lay out an org chart, each agent fills one role, you talk to the person at the top, and the org sorts out the work between them. You already know how a company works, so you already know how to run one here. There is no new abstraction to learn. That is exactly what Alook does. Each agent is a live Claude Code or OpenCode session with a defined role, a reporting line, and its own email inbox. The agents coordinate over email, the same way a team would. And it all runs locally through a runtime on your own machine, so nothing leaves your setup. You bring your own agent too. Claude Code and Codex both work, and if you would rather stay fully open source and local, OpenCode works the same way. To show how this feels in practice, I set up three agents as a small sales team. Vi is the one I talk to. I hand Vi a goal, and Vi routes the work down the chart. Neile runs prospect research. Vi passes the target criteria, and Neile reports back a ranked list of names, roles, and companies, each with a suggested angle and a confidence score. Lliane runs outreach. Vi hands over the messaging angle and follow-up cadence, and Lliane reports back on emails sent, responses received, and any deal that needs escalation. I never relay a message between them. Neile and Lliane report to Vi, and Vi updates me in one place. The whole thing is open source and self-hosted, so it runs on your machine with your own agents. Give the repo a star if you want to follow where it goes: I also wrote a full walkthrough on building your own AI company with it, from a blank org chart to a running job. The article is quoted below. Cheers! :)

How to setup your Claude code project? TL;DR Most developers skip the setup and just start prompting. That's the mistake. A proper Claude Code project lives inside a .𝗰𝗹𝗮𝘂𝗱𝗲/ folder. Start with 𝗖𝗟𝗔𝗨𝗗𝗘.𝗺𝗱 as Claude's instruction manual. Split it into a 𝗿𝘂𝗹𝗲𝘀/ folder as it grows. Add 𝗰𝗼𝗺𝗺𝗮𝗻𝗱𝘀/ for repeatable workflows, 𝘀𝗸𝗶𝗹𝗹𝘀/ for context-triggered automation, and 𝗮𝗴𝗲𝗻𝘁𝘀/ for isolated subagents. Lock down permissions in 𝘀𝗲𝘁𝘁𝗶𝗻𝗴𝘀.𝗷𝘀𝗼𝗻. There are two .𝗰𝗹𝗮𝘂𝗱𝗲/ folders: one committed with your repo, one global at ~/.𝗰𝗹𝗮𝘂𝗱𝗲/ for personal preferences and auto-memory across projects. The .𝗰𝗹𝗮𝘂𝗱𝗲/ folder is infrastructure. Treat it like one. The article below is something I wrote three months ago, and it is still very much relevant. It is a complete guide to 𝗖𝗟𝗔𝗨𝗗𝗘.𝗺𝗱, custom commands, skills, agents, and permissions, along with how to set them up properly.

The harness is what matters now. The model is just a commodity. A model on its own returns text. Nothing it produces becomes working code until something around it reads the repo, applies the edits, runs the tests, and reacts to what breaks. That something is the harness, and it decides how much of a model's ability actually ships. Cline ran a clean test of this. Same model, GLM 5.2, on the same set of coding tasks, driven two ways by their harness. - 57.3% with reasoning turned off. - 68.5% with reasoning turned on. The weights never changed. The only difference was how the harness drove the model. Reasoning budget is one knob. The harness also decides what context the model carries across steps, which tools it can reach, how edits get applied, and whether the work gets checked before it moves on. This is why the model is becoming the swappable part. The open ones are strong enough now, so what separates a good run from a wasted one is the environment they run inside. Cline is an open-source harness built for exactly this. The model is a slot you fill, and the loop around it stays the same whether you run GLM 5.2, Kimi K2.7, or DeepSeek V4. ClinePass is the clean version of that idea. One subscription to bring those open models into the harness, without assembling the stack yourself. A few things follow from the design. → It curates the field. The set is narrowed to open models tested for coding-agent use, so you skip finding out the hard way which ones hold up across long tasks. → It drops the provider sprawl. One subscription covers them, with no separate accounts, keys, or billing to track across labs. → It runs longer. The quota gives 2 to 5x the standard API rate limits, so long agent runs don't stall mid-task. → It stays open. Custom keys and local models keep working alongside it, so it adds an option instead of replacing what you have. The point is not which open model wins. It is that the harness that decides the outcome now, and the model is just the part you swap in. The video below shows the setup in action. I worked with the team to put it together.

Karpathy's Agentic Engineering finally has proper tooling! (built by Google) Karpathy defined agentic engineering as the discipline that separates production agent work from vibe coding. The core skills he listed were spec design, eval loops, and security oversight. The problem has been that practicing this still requires a different tool for every phase: - editor for code - a terminal for scaffolding - a browser for testing - a cloud console for deployment - and a separate framework for evals. Every transition is a context switch. The solution to production-grade Agentic Engineering is now actually implemented in Google’s Agents CLI. It covers the entire workflow in one place for scaffolding, evaluating, and deploying ADK agents. One setup command injects 7 ADK-specific skills into a coding agent's context, which lets it handle scaffolding, evals, deployment, and enterprise registration through natural language. I tested this end-to-end by building a RAG agent from scratch using Claude Code. It scaffolded the full project from the ADK agentic_rag template, generated 20 eval scenarios with LLM-as-judge scoring, and returned a quantitative scorecard. Finally, it also deployed everything to Agent Runtime and registered the agent to Gemini Enterprise, so the entire org can discover and use it. The video below shows this in action, and I worked with the Google Cloud team to put this together. Agents CLI GitHub repo → (don't forget to star it ⭐ ) I wrote up the full build covering all six steps from install to enterprise registration. It includes the eval scorecard, the instruction loophole the eval caught before deployment, and what the deployment process actually looks like end-to-end. Read it below.

Web scraping will never be the same. (100% open-source visual search at scale) PixelRAG is a retrieval system that skips HTML parsing completely. Instead of scraping a page into text and embedding chunks, it screenshots the page and retrieves the image. A vision-language model reads the answer straight off the pixels. Why that matters: parsing is where web RAG quietly loses information. - A single HTML-to-text parser can drop 40%+ of a page. - Tables, charts, and layout get flattened or thrown out. - Swapping parsers alone can move accuracy ~10 points on the same docs. PixelRAG indexes the page a person actually sees. The team built a visual index of all of Wikipedia, 30M+ screenshots, and it still beats the strongest text RAG baseline by 18.1% on text-only QA. The repo also ships a Claude Code plugin that gives Claude eyes. It lets Claude screenshot any URL and read the rendered page instead of scraping the DOM. So you can hand it a live page, an arXiv paper, or your local site and ask what it actually looks like. One setup script. No MCP server, no backend. How the pipeline works: - Renders each document (web, PDF, image) to image tiles. - Embeds them with Qwen3-VL-Embedding, LoRA fine-tuned on screenshots. - Builds a FAISS index and serves a search API. A stronger reader model lifts accuracy with no re-indexing, since the index is just pixels. Everything is open-source under Apache-2.0. GitHub repo: Talking about RAG, I recently wrote an article on a new approach that makes retrieval much more efficient by cutting corpus size by 40x, reducing tokens per query by 3x, and improving vector search relevance by 2.3x. The article is quoted below.

the three-tier memory of Hermes agent. AI agents forgets everything when your session ends. Hermes doesn't. it has three memory layers, each at a different speed. 𝘁𝗶𝗲𝗿 𝟭: 𝘁𝘄𝗼 𝘁𝗶𝗻𝘆 𝗺𝗮𝗿𝗸𝗱𝗼𝘄𝗻 𝗳𝗶𝗹𝗲𝘀 MEMORY.md (2,200 chars) and USER.md (1,375 chars). injected into the system prompt at session start as a frozen snapshot. MEMORY.md holds project conventions, tool quirks, lessons learned. USER.md holds your profile: name, communication style, skill level. these files are tiny on purpose. when MEMORY.md hits ~80% capacity, the agent consolidates: merges related entries, drops redundancy, keeps only the densest facts. natural selection pressure applied to memory. the files stay small, but what's inside gets sharper over time. 𝘁𝗶𝗲𝗿 𝟮: 𝗳𝘂𝗹𝗹-𝘁𝗲𝘅𝘁 𝘀𝗲𝘀𝘀𝗶𝗼𝗻 𝘀𝗲𝗮𝗿𝗰𝗵 (𝘀𝗾𝗹𝗶𝘁𝗲 + 𝗳𝘁𝘀𝟱) every conversation gets stored in SQLite with FTS5 indexing. the agent can search weeks of past sessions on demand. when the agent calls session_search: FTS5 ranks matches in ~10ms over 10,000+ docs, an LLM summarizes the top hits, and a concise result returns to context. tier 1 is always present but tiny. tier 2 has unlimited capacity but requires an active search. critical facts live in memory, everything else is searchable. 𝘁𝗶𝗲𝗿 𝟯: 𝗲𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗺𝗲𝗺𝗼𝗿𝘆 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗿𝘀 8 pluggable providers that run alongside tiers 1 and 2, never replacing them. three worth knowing: Honcho (dialectic user modeling, 12 identity layers), Holographic (local-first, HRR vectors, no external calls), and Supermemory (context fencing that prevents the same fact from being re-stored infinitely). when active, hermes auto-syncs every turn: prefetch before, sync after, extract at session end. 𝗵𝗼𝘄 𝘁𝗵𝗲𝘆 𝗰𝗼𝗺𝗽𝗼𝘀𝗲 𝗶𝗻 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝘁𝘂𝗿𝗻 this is the part most people miss. the tiers compose on every turn through a five-step cycle: 1. turn opens. tier 1 is already in prompt, tier 3 prefetches and prepends. 2. agent responds using all three tiers as context. 3. periodic nudge fires (~every 300s). the agent reflects: "has anything worth persisting happened?" if yes, it writes. if no, it returns silently. 4. memory written to MEMORY.md on disk. invisible this session because the prefix cache stays warm. 5. session closes. tier 2 logs the transcript, tier 3 extracts semantics. next session opens with the new state. agent memory today is either always-on but shallow (stuff everything in the prompt) or deep but passive (vector store that never fires at the right time). hermes composes across both: tiny always-present files for critical facts, full-text search for deep recall, external providers for semantic modeling, all orchestrated by a nudge that decides autonomously what's worth saving. the agent doesn't just store memories. it curates them under pressure. i wrote a full deep dive (article below) covering hermes agent's memory system, self-evolving skills, GEPA optimization, and how to set up multiple specialized agents on your machine.