What I learned shipping the first agent

Patient work, woven in public.

This is Thread 10 of Loomwork — the close of the prologue. New here? Thread 01 explains why this newsletter exists — 2 minutes.

The first agent has been live for a week. Long enough to notice things. Short enough to still remember the decisions that produced them.

Three observations. One worked better than I expected. One I have to redesign. One was an assumption I had wrong from the start.

What worked better than I expected

When I drew the architecture, I treated the findings store as the boring piece. Specialists append findings; the chief of staff reads them; and a finding is deliberately loose — a kind, and a blob of detail, nothing rigid. I picked that because it was simple, not because I was sure it was right.

A week in, it's absorbed things I didn't design for. When I added a brand-new kind of check, it started writing a new kind of finding — and the chief of staff picked it up with no code change, because it reads the parts it understands and ignores the rest. When an agent failed partway through a run, the findings it had already written were simply there, and the next run carried on. And when I wanted to look back at what an agent saw on a given morning, it was one query away.

A rigid schema would have made the first a migration and the second a special case. The loose shape keeps paying interest.

Simple primitives chosen well outlive sophisticated systems chosen quickly.

What I have to redesign

The chief of staff writes one briefing each morning. That assumption came from "morning person reads with coffee" — a reasonable picture, but not the only one. A week of actually using it, and the briefing's value decays faster than 24 hours but slower than 12. The right cadence is probably twice a day.

The run time is already the operator's to set. What I haven't built is the frequency — once versus twice a day — and that gap exposes something larger: a senior engineer at a regulated company won't want the same rhythm as a solo builder. The rhythm has to be the operator's choice, not a number I picked.

I don't list this as a flaw. I list it as evidence that the right design only becomes visible once the system is in your daily use. The thing to redesign is rarely the thing you suspected.

The assumption I had wrong from the start

I built the specialists read-only and called it a safety stance. It was the right safety stance. It was the wrong product stance.

The single most valuable thing the briefing surfaces every morning is something I then have to act on by switching to another tab and running a command. That switch is real. The right next move for the briefing isn't to surface more — it's to propose the action and let me approve it with a single tap.

That's a write capability. It needs an approval flow I waved at early and haven't built. The wave was easy because I wasn't yet feeling the friction. Now I am.

What's next, in steady state

The foundation is in place. The next chapters aren't another prologue — they're one product getting deeper. A second specialist is queued. Voice input is queued. An observability surface, so I can see when an agent is degrading, is queued. None of these are new commitments; they're the obvious next steps for the same thing.

If you've followed the ten-week prologue, what you've watched is one solo builder — with a day job and limited hours — think about, architect, and ship a small but real agentic system end to end, on the timeline he set. That's the proof.

The rest of Loomwork is what I do with that proof.

Thanks for being here.

— Vamshi

Loomwork is by Vamshi Krishna Veggalam. Building Foundry at mindloomhq.com. Find me on LinkedIn.