how I’m building an agent company inside my agency. the structure looks like this: Agency gBrain → Orchestrator Hermes Agent → Department verticals → Specialist agents → Scoped sub-agents gBrain is the company brain. It gets ingested with the data and experience we already have: > transcripts > chats > previous campaigns > client learnings > strategy docs > internal workflows > examples of what good looks like That brain is maintained by a human champion plus an orchestrator Hermes Agent. Under the orchestrator, we have different department verticals inside the agency. Each vertical has its own specialist agents. Some of those specialist agents have even narrower scoped agents underneath them. I’ve found that narrow scope improves output quality and reduces drift. > a general “marketing agent” is too vague. > a lifecycle email agent with access to the right campaigns, voice rules, approval gates, and examples can get very good. > a technical SEO agent with its own tools, checklists, and source standards can get very good. > a content research agent with narrow inputs and a clear definition of done can get very good. The narrower the job, the easier it is to improve the agent. I use different harnesses for this. Mostly Hermes Agent, but also CLI harnesses like Codex and Claude Code depending on the job. I’m still looking for a good bare-bones harness for model routers to run on. To keep track, I maintain an org chart inside the company gBrain. The org chart shows: > top-level orchestrator > department verticals > specialist agents > scoped sub-agents > which brain each agent reads from > which tools each agent is allowed to use > where human approval is required For clients, I do downstream pods. Think of them as new agent companies that are isolated from the agency brain, but can still communicate with our agency agents when needed. A client pod has its own: > client gBrain > client orchestrator > client specialist agents > client-specific workflows > client-specific approvals > client-specific memory This is important. You do not want client context bleeding across accounts. You do not want one agent with every client’s data, every tool, and every permission. Scope is what keeps the system useful. The powerful part is that once you build one vertical agent well, you can fork it. Not copy-paste blindly. You still need to customize the context, examples, approvals, voice, tools, and workflows. But you are not starting from zero. You might have 75% of the agent already done. That changes the agency model. You no longer need a full traditional department for every function before you can deliver a well-rounded marketing service. One or two strong marketing engineers can run an output surface that used to require a much larger team. But this only works if the agents are actually good. It takes iteration, taste, source material, QA, workflow design, and real marketing experience. Bad agents do not become good because you connected more tools. Vague agents just create vague output faster. TLDR: > turn the agency’s knowledge into a brain > turn repeated work into scoped agents > turn each client into an isolated pod > let skilled operators run the system

1 for "context engineering" over "prompt engineering". People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step. Science because doing this right involves task descriptions and explanations, few shot examples, RAG, related (possibly multimodal) data, tools, state and history, compacting... Too little or of the wrong form and the LLM doesn't have the right context for optimal performance. Too much or too irrelevant and the LLM costs might go up and performance might come down. Doing this well is highly non-trivial. And art because of the guiding intuition around LLM psychology of people spirits. On top of context engineering itself, an LLM app has to: - break up problems just right into control flows - pack the context windows just right - dispatch calls to LLMs of the right kind and capability - handle generation-verification UIUX flows - a lot more - guardrails, security, evals, parallelism, prefetching, ... So context engineering is just one small piece of an emerging thick layer of non-trivial software that coordinates individual LLM calls (and a lot more) into full LLM apps. The term "ChatGPT wrapper" is tired and really, really wrong.