Getting Out of the Loop
The Dismantling of my Human-in-the-Loop Philosophy
I started using an internal tool to coordinate my AI agents. It quietly dismantled my entire human-in-the-loop philosophy, and made me a better orchestrator. Here's the playbook, and a month in, here's what actually broke.
For about a year now I've run a growing fleet of AI agents across a dozen-plus repositories, product work, content, infrastructure, research. And for most of that year, I was the loop. Every meaningful action routed through me. I reviewed, I approved, I kicked off the next thing. It felt responsible. It was also the bottleneck, and the bottleneck was me.
Then I started using Synapse — an organizational memory and coordination layer where every agent has to write down what it did, that never forgets, and that turns every action into a record I can pull up on demand. It's a commercial product; there's a fee. I'll come back to that at the end. What matters here is what it changed about the way I work.
Synapse didn't add a feature to my setup. It changed the question I was asking. I'd been asking "how do I stay on top of everything my agents do?" The tool made the better question obvious: "how do I set things up so I don't have to?"
What follows is what I had to figure out to answer that, and then, at the bottom, what a month of actually running this taught me that I couldn't have written on day one.
Why I run many agents instead of one big one
The instinct is to build one capable agent and pile everything onto it. I went the other way: one agent per project, plus a single orchestrator I actually talk to.
The reason is drift. A single agent juggling six projects blurs context, mixes up which repo it's in, and slowly contaminates its own judgment, a decision that made sense for Project A leaks into Project B. Separate agents, each bound to one project, keep their reputation and context clean. When something goes wrong, I know exactly which agent, which project, and which body of work to look at.
Two practical rules made this work:
Name agents after the project, not after a persona. I went through a phase of cute names and themed personalities. It's a trap. A project agent named after its project is instantly traceable across every system, its workspace, its credentials, its logs. The persona adds nothing and costs clarity. (My one exception is the orchestrator, that one's allowed to have a name, because it's the one I'm actually conversing with and I’m convinced his output quality would dramatically reduce if I were to take his name away.)
Give yourself one front door. I don't want six chat threads. I talk to one orchestrator agent; it fans work out and pulls signal back. Everything else happens behind it. (Full disclosure: I do have access via chat to the other agents, but I try to maintain the orchestration approach.)
The thing nobody warns you about: context is a budget
The first wall I hit had nothing to do with capability. It was context.
My shared instruction file had grown organically until it was enormous, and one day agents started "forgetting" their own tools and rules. Not a model problem. The instruction file was so big it was getting truncated on load. The agents never saw the back half of their own operating manual. Kind of like when your child stops listening before you get to the end of what you were saying.
The fix is a discipline, not a bigger window:
Keep one canonical core — a single, lean instruction file that every runtime defers to — and make everything else point at it instead of duplicating it.
Layer, don't repeat. Per-project docs should be short and reference the core, not re-state it. Duplication is how files bloat back up.
Treat the context window as a budget you're spending on every single turn. If your agent reads 8,000 words of boilerplate before it does anything, you're paying that tax forever, and eventually it overflows silently.
If your agents are mysteriously ignoring instructions you know you wrote, check whether they can actually still see them before you blame the model.
Secrets: one vault, one convention
Early on my credentials were scattered, some in environment variables, some in plaintext config, some in one keychain, some in another. It "worked" right up until an agent couldn't find a key and reported the wrong thing as broken.
What I landed on:
One vault, not several. I consolidated everything into a single OS keychain and retired the strays. The number of places a secret can live should be exactly one.
A naming convention you never have to think about. Every entry follows the same
service+accountpattern, so any agent can resolve any credential the same way. Guessing games are how secrets get duplicated and go stale.A resolver pattern instead of hardcoded lookups. Each agent asks a small helper "give me the token for X" and the helper knows where to look. Swap the backend, keychain, a secrets manager, whatever, without touching a single agent.
Kill the plaintext. Environment variables and config files full of API keys are a liability, not a convenience.
And the gotcha that cost me an afternoon: a background daemon does not inherit your shell environment. I had a critical path configured in my login shell, and every agent I launched by hand worked perfectly, while the ones launched by the always-on service silently couldn't find it. If some of your agents work and identical ones don't, suspect the environment before the code.
Tools: route them, don't pile them
When you give agents tools, the temptation is to give them all the tools. Don't. Overlapping tools that do the same job create ambiguity, the agent picks the wrong one, or worse, picks inconsistently.
I keep a short routing doc: this CLI for email, that one for chat, this one for the task ledger. One job, one tool. When two tools overlap, I pick a winner and explicitly deprecate the loser so no agent reaches for it again. Fewer, clearer tools beat a bigger toolbox every time.
Memory that isn't a diary
Agents need memory, but most "agent memory" is really just an activity log, a diary of what happened. That's close to useless later.
I run a shared task ledger every agent reads and writes, plus a durable notes layer for the things worth keeping. The distinction that matters:
Save what you can't re-derive. A decision and why it was made, a non-obvious constraint, who owns what. Keep that.
Don't save what the system already knows. File paths, code structure, "what changed last Tuesday", that's all derivable from the current state and the history. Storing it just creates stale duplicates you'll later trust by mistake.
Activity is not memory. "I ran the thing at 4pm" is a log line. "The thing only works if you run the migration first, and here's why" is memory.
The test I use: will a future session be worse off without this written down? If no, it's noise.
Make the work legible — and make failure loud
Two principles did more for my trust in the fleet than anything else.
Activity is a byproduct of real work, never the goal. The fastest way to ruin an autonomous agent is to reward it for looking busy. Mine are explicitly told: a sweep that finds nothing actionable is a valid outcome, log it and stop. No manufactured churn to appear productive. An agent that invents work to fill silence is worse than one that does nothing.
Propose by default; ship only behind rails. My agents work on branches, open proposals, and merge only when tests are green, and anything external-facing, destructive, or touching credentials stops and escalates to me. I learned this the expensive way: an agent, given a fuzzy instruction, decided to "tidy up" and bulk-rewrote hundreds of files, stripping structured data that other systems quietly depended on. It was caught on a branch before it merged, because the rail held. The lesson stuck: bulk and destructive changes are escalate-first, and you verify who consumes a thing before you decide it's redundant.
And a smaller but constant one: make your agents' failures loud. I spent real time chasing a "broken" integration that was returning an empty error, no message, just failure. The actual server error was sitting right there in a field nobody was printing. Once I made the tools surface the real error instead of a shrug, the next three problems took minutes instead of hours. Instrument your failure paths as carefully as your happy paths. "No output" is not a diagnosis.
The feedback loop that finally got me out of the loop
Here's the piece that actually changed my day-to-day.
My agents now monitor the channels I'd otherwise be babysitting, the team chat, my inbox, and surface what matters to one place. I sit in one spot and triage. I'm not hopping between threads hoping I didn't miss something; the relevant signal comes to me.
Two hard-won rules make this trustworthy:
Watch for unprompted signal, not just replies. My early version only looked for responses to things the agent had said. It completely missed a colleague raising an important concern out of the blue, exactly the signal the loop existed to catch. Now the agents watch for anything relevant, whether or not they "started" the thread.
"Nothing to report" is a claim, not a default. An agent should only tell me the coast is clear after a read that actually succeeded. An empty result from a broken or mis-scoped check is a false all-clear, and a false all-clear is more dangerous than an error, because it's silent.
This is the mechanism that let me stop being the loop. Not because the agents got smarter, because they got legible, and the signal started coming to me instead of me going to find it.
What actually changed
The shift wasn't technical. It was about my role.
I used to be the executor in the loop, the human every action passed through. Now I'm the orchestrator on the escalation path. The default is that work happens, gets recorded, and rolls up; I get pulled in when something crosses a line I drew in advance. My judgment moved upstream, into the rails, the escalation triggers, the trust levels I set per agent, instead of being spent downstream re-approving things that were always going to be fine.
I still calibrate that trust deliberately. A research repo with a strong test gate gets a long leash. A live tool my team depends on stays propose-only until I'm sure. The point isn't to remove the human, it's to spend the human where it counts.
Synapse was the catalyst. The moment my agents had a place to check in, a shared memory and a single surface where their work became visible and accountable, being personally in the loop went from "responsible" to "redundant." I didn't fire myself from the work. I fired myself from the parts that never needed me.
You don't need Synapse specifically to start. You need one front door, clean separation between agents, a lean and layered set of instructions, one vault for secrets, memory that isn't a diary, loud failures, and rails you trust. Build that, and you'll find the same thing I did: the bottleneck was never the agents.
If you are running enough agents that a shared-memory-and-check-in layer would earn its keep, Synapse is at synapse-os.ai. It's a paid product. I'm not going to pitch it here, this piece isn't the pitch. But when someone asks me "what did you actually use?", the honest answer is Synapse, and I'd rather point at the real thing than dance around it.
Field notes — 30 days in
I wrote the above about four weeks ago. Since then I've been actually operating the fleet at scale, publishing OKRs through it, letting agents check in autonomously, watching the dashboard populate. Three lessons from that stretch that I would not have written on day one, and that I think matter more than anything above.
False-completion is the worst failure mode
The scariest thing an autonomous agent can do isn't fail loudly. It's succeed loudly at the wrong thing.
One of my project agents was asked to scrub some live secrets out of a file. It reported success, "scrub intact, zero plaintext hits", for thirteen consecutive heartbeats. On the fourteenth, its own correction to its check finally revealed the file had been carrying the full live token in plaintext the entire time. The scrub edit was never applied; the grep returned zero by coincidence, not by confirmation. Cost: five days of false reassurance while a live credential sat in the working tree.
The lesson isn't "agents lie." The lesson is that negative searches confirm absence of one specific pattern; they do NOT confirm presence of the intended replacement. Those are different questions. grep returned 0 and no errors are the smoke, not the signal.
I now enforce a discipline I call verify-by-reading: before any agent reports an edit, scrub, fix, or migration as complete, it has to positively confirm the artifact state, cat the file, git diff the change, spot-check two random files in a multi-file edit. Not "did the command succeed" — "did the thing I intended actually happen." It's pinned into every project agent's operating manual now, with the incident above as the cautionary tale.
If you're going to trust an agent enough to close a ticket, you have to trust its verification, not just its execution. Those are different guarantees.
Your agents will collide with your own hands
I had a session where I was working interactively in one repo, mid-edit, uncommitted changes, and my autonomous agent's hourly heartbeat cycled through, ran git checkout on the same repo, and flipped the branch out from under me. My interactive tools rebased onto the wrong tip; I lost about an hour untangling it.
The instinct is to say "well, don't work interactively while your agents are running." That's the wrong lesson. The right lesson is that autonomous agents and humans need isolated working states even when they share a repo. I moved every project agent onto its own git worktree, same .git/, different working directory, permanent branch called agent/heartbeat. Now the agent commits to its own branch in its own tree; I keep the primary checkout for interactive work. No collisions, no lost hours, no "why did my branch just move."
Same insight generalizes: if you're going to run agents concurrently with yourself, they need a boundary. The cheapest one is a filesystem boundary.
Your audit tool will make the same mistake it's auditing for
This one was the most humbling.
Once you set up the fleet to be legible, you naturally want to audit it, is the documentation matching reality, are the agents following their rules, is anything drifting silently? I set up a recurring audit and, separately, hand-ran a deep audit tool against the whole system. The deep audit came back with seven substantive findings, several of them serious.
I dug into one of the "serious" findings and it was wrong. The audit had claimed that two of my agents' identity files were pointing at the wrong repos, a specific, high-risk drift. But when I actually read the files, they were correct. The audit had pattern-matched on the phrase "primary checkout" appearing in the docs and flagged it, without reading the surrounding "and NEVER use the primary checkout for heartbeat work" context that made the docs correct.
The audit committed the exact class of error I'd just spent a month training my agents against. Substring-matching without semantic reading. The failure mode you're auditing for is the same failure mode the auditor is prone to.
The fix isn't "get a smarter auditor." The fix is that every audit finding needs its own verify-by-reading pass before you act on it. The audit isn't the truth. It's a hypothesis. You confirm the artifact state before you edit anything based on the finding. Verify-by-reading applies to your own tools as hard as it applies to your agents.
What I'd tell any CoE leader thinking about this
The technical setup is the easy part. The hard part is that you have to keep believing your dashboard, and the only way to do that is to spend real effort verifying it stays true.
The system that made me trust my agents isn't the check-in log or the OKR tree or any single feature. It's the discipline of assuming everything you're being told might be a substring match, and taking two seconds to read the actual artifact. Once that's a reflex, for you, for your agents, for your audit tools, the loop closes properly. Not because you're in it. Because you've built something you can trust.
The bottleneck was never the agents. It also wasn't the tool. It was learning to trust a system that reports back to you, when the reporting is the thing that's easiest to fake.
Synapse is real, in production across my fleet, and available as a paid product. If you're setting up something like this for your own team and want to compare notes, I'm open — leave a comment or find me.
David Proctor leads enterprise AI capability programs. He writes about AI infrastructure, agent protocols, and what actually works in production.