The architecture I'm betting on for the first agent

Vamshi Krishna V.

Patient work, woven in public.

This is Thread 06 of Loomwork. New here? Thread 01 explains why this newsletter exists — 2 minutes. Last Sunday I described the control system that lets an AI ship my code; this week is the bet on what it builds.

Last week was about the controls around an AI building software. This week is about what it builds next — and the bet I'm making on the shape of it.

Before I build the first agent, I have to decide what kind of thing it's part of. One giant agent that tries to do everything? A pipeline of LLM calls glued together with custom code? Or something else? The shape of the answer determines every model choice, every credential, every safety decision that follows.

The bet I'm making is the third option: a small constellation of specialist agents reporting to one master that synthesizes. Here's the diagram, then the reasoning, then the three things I'm not sure about.

Five pieces.

Specialist agents — one per system that matters. A GitHub specialist to watch PRs and issues. A Vercel specialist to watch deploys and errors. A Stripe specialist to watch MRR signals and payment failures. Each one small, scoped, running on its own schedule. And — this is the part that matters — none of them with write access to anything.

A findings file — append-only. Each specialist would write its observations to a single newline-delimited file. No database call, no API, no real-time streaming. The file is the contract. If a specialist crashes mid-run, the file has whatever it wrote up to that point and the next run continues cleanly. If a new specialist arrives, it appends to the same file. Boring, durable, debuggable with a text editor at 2 a.m. when something's wrong. The point of choosing a file over a database isn't simplicity for its own sake — it's that a file survives every failure mode I can imagine and a database doesn't.

A master agent — running once per day. Reading the day's findings, deduplicating, prioritizing, writing one briefing. Aware of the operator's context — which projects are in flight, what's deferred, what week of the year it is. The master is the only agent that would produce output the operator reads directly. Everything else feeds it.

A briefing surface in the product. The operator would open it the way they open email — when they're ready. No notifications, no badges, no alerting. Plain text first, then surfaced anomalies, then suggested next actions.

An audit trail — every specialist run, every master synthesis, every prompt and every response logged with timestamp and token count. The operator can scroll back and ask "what did the GitHub agent see on June 3rd?" and get a real answer. Not a nice-to-have — the only way a system that spends tokens on your behalf earns trust over time is by being inspectable after the fact.

The shape of the architecture I'm betting on is, in one line: specialists observe, the master synthesizes, the operator decides.

The safety choices — at the architectural layer, not the application layer.

Three of them, and they all live in code rather than in policy documents.

Read-only credentials only. Every specialist would get a token scoped to read only what it watches. A GitHub specialist that can list PRs, read diffs, read issue comments — but cannot open a PR, post a comment, or push a commit. A Vercel specialist that can read deploys and logs, but cannot trigger a rollback or change an env var. Enforced at the credential layer, not at the prompt layer. There would be no way for the agent to escalate, because the API token wouldn't permit it. If I later want a write-capable agent, that's a separate, deliberate decision with its own credential and its own approval flow.

A cost ceiling enforced in code. Every agent would check a running spend tally before each model call. Past a warning threshold the system degrades gracefully — only the master runs, the specialists stand down. Past the hard ceiling, every agent stops with a clear error. Where the limit lives is the whole point: in the model client, changing what the code actually does — not in a billing alert that emails you after the money is already spent. A system that can spend on your behalf should be the same system that structurally refuses to overspend.

A human gate before anything consequential. Agents would observe and propose; they wouldn't act. The master could tell you "this deploy has failed three times, here's the likely cause" — it could not re-run the deploy. The line between proposing and acting is drawn deliberately, and stays drawn until I move it.

That last principle isn't theoretical for me — I watched it earn its place last week, on the build side. When I added authentication to Foundry, the plan-gate I described in Thread 05 made the AI produce the design before any code. The approval turned out to be the easy part. The valuable part was where it paused mid-design: it reached a data-isolation question it couldn't safely answer on its own, and rather than guess, it stopped and surfaced the question. A gate that only ever says yes is theater. The proof that this one is real is the honest pause.

Why one master and many specialists, not one big agent.

A single agent watching everything has to keep all the context in its working window. Token cost runs nonlinear in many places, and reasoning quality drops as the context fills. The specialist pattern would reduce each agent's working set to one system; the master would only synthesize already-distilled findings. Cost stays roughly linear in the number of systems instead of compounding.

There's a second reason that matters more long-term. Each specialist can be replaced or tuned independently. The GitHub specialist might start as a Sonnet call and become a fine-tuned Haiku call in a year. The master might evolve from synthesis to a learned classifier. The architecture absorbs those substitutions without changing its shape. A monolithic agent doesn't give that — every model swap is a rewrite.

What could be wrong about this bet.

Three things I'm not certain about, in honesty.

The first is whether one master can hold enough context to synthesize across many specialists well. With two or three specialists feeding into a 200K-token window, the math says yes. By specialist seven or eight, I'd expect to be picking which specialists feed the master on which days — a routing problem I haven't designed yet. If that turns out to be harder than I think, the architecture has to grow a synthesis layer between specialists and master, which is a piece I'm currently not paying for.

The second is whether the findings file survives schema evolution. Append-only files are wonderful until you want to query them differently. I have a half-formed plan to migrate findings into SQLite once volume justifies it. I'm betting that volume comes well after the architecture is otherwise stable. If it comes earlier, this is the first thing that has to change.

The third is whether read-only credentials are enough. Some of the most valuable agent work involves triggering something — re-running a failed deploy, opening a draft issue, sending an alert. Today I refuse all of those. If a year from now my biggest unmet need is a write-capable agent, the safety architecture has to grow an approval flow and I have to agree to it. That's possible. Today I'd rather under-promise on capability than over-promise on safety.

Next Sunday: Auth shipped. Here's what changes now. The Phase clerk fork — what real authentication unlocks, what it costs, and the decision tree it puts in front of every feature from here on.

See you then.

— Vamshi

Loomwork is by Vamshi Krishna Veggalam. Building Foundry at mindloomhq.com, with the full archive at loomwork.dev. Find me on LinkedIn.