r/ChatGPTCoding • u/New_Difficulty_8152 • 20h ago
Discussion Two ways I tried and failed to manage context across multiple AI agents, and what I built instead
I keep seeing this question in the community. Here's what I actually tried, why it broke, and what I ended up shipping.
The problem
When you're running multiple agents across a session (one that writes, one that reviews, one that deploys) you need them to share state. Not just conversation history. Actual verified state: what changed, what's blocked, what evidence exists that a task is done.
What I tried first (and why it failed)
Attempt 1: I maintained the handoff notes myself
After every session, I updated a Markdown file. This worked until I finished tired and skipped the update. The next agent read stale context as if it were current. Worse: even when the file was accurate, I was still the router, a human bottleneck between every agent transition.
Attempt 2: I let agents maintain the notes
The agent finished its work, updated the handoff, and the next continued from there. Then I noticed the real problem: an agent could write "tests pass" just as easily as it could actually run the tests.
Agent A would write: "Refactored auth. Tests pass."
Agent B had no idea which tests ran, against which version, or whether the slow integration suite was skipped. It didn't inherit verified work. It inherited a story about the work.
What I built
Three principles became the foundation:
State in fields, not paragraphs. What changed, what's blocked, what's unresolved as explicit fields, not embedded in a summary. An agent can't make unresolved work disappear by writing a nicer paragraph.
The agent that does the work can't approve it. A separate reviewer starts from the original goal and inspects the result directly, not from the implementing agent's explanation of why it's probably done.
Machine-checkable claims need evidence attached to a specific version. "Tests pass" is a claim. A test result attached to the exact commit hash is evidence. If the code changes after the evidence was produced, the evidence doesn't automatically transfer.
This became an open-source project (link in comments).
Results over 30 days of dogfooding
4,172 PRs merged across 16 repositories, one maintainer
Coordination overhead stayed roughly flat from 3 agents to 10; adding agents stopped adding to my mental load linearly
Stale-context bugs dropped to near zero because agents can't declare victory without attached evidence
The number I actually care about: my day looks the same with 3 agents as with 10. That wasn't true before.
What didn't work
The reviewer agent still occasionally fails to distinguish "the goal changed mid-task" from "the implementation is wrong." We handle this with an explicit goal-hash that both agents reference, but it adds friction. Still working on the right UX for that.
Has anyone else hit the "agent self-reports done but the work isn't clean" problem? Curious what enforcement patterns people are using, if any.
1
u/Academic-Tie6223 20h ago
I've been through this exact mess, the manual tracking always gets stale by the third agent. A shared state file that agents read and write as JSON is the only thing that's worked for me.
2
u/No-Jackfruit-9016 20h ago
That's the thing, once you have three or four agents going, no human can keep the details straight, so having the machines do it just makes sense.
1
u/DevWorkflowBuilder 17h ago
we gate on a FAILING_CHECKS.md the worker has to clear after a real CI run, not its own "done" line. if that file still has rows, the PR stays draft. does your goal-hash catch silent no-ops or only the goal text?
1
u/Enough-Photo9140 13h ago
The narrative handoff vs machine-checkable evidence breakdown is spot on.
We ran into the exact same failure mode where an agent would write "refactored auth module, verified edge cases" in the markdown log, but when inspecting the actual terminal run, it just ran an empty linter or exited 0 on a dummy mock.
The cleanest solution we found was decoupling claim generation from claim verification: require every state assertion to bind directly to a verifiable receipt (like a tool exit code, a structured diff hash, or a live platform read-back) rather than free-form prose. If there is no receipt in the event log, the state transition is rejected outright.
1
u/kirbyhood 12h ago
I feel like agent orchestrators like Orca and bb solve a lot of this for you right? How is this different?
1
u/me-shaharia 11h ago
Evidence produced by the agent is still the agent's word. Mine would run a scoped subset of the suite, see green, and attach that as proof of done. What fixed it was moving the check outside the agent: a hook runs the tests on stop and the exit code writes the field, so the agent never gets to type "tests pass" at all.
On the goal-hash friction, does your reviewer re-derive the goal from the original request, or does it read the implementer's restatement of it?
1
u/aidiveyt 42m ago
Same failure on a video pipeline. A design subagent kept reporting 'stills verified' and they weren't. We stopped trusting the handoff note and made the orchestrator render one still per segment itself before anything moves on.
2
u/New_Difficulty_8152 20h ago
Repo is here if anyone wants to poke at it: https://github.com/kungfu-systems/kungfu
Honestly the fastest way to evaluate it is to point your own agent at it instead of reading my pitch. Something like:
Take a look at https://github.com/kungfu-systems/kungfu. Start from the entry points laid out in AGENTS.md to understand how it works, then tell me what problem it actually solves and what you think of the architecture.
You'll get a straighter answer than anything I'd write here.
Genuinely want criticism on this one, especially from anyone running a setup that already works for them. And if you've solved the disappearing open problem thing some other way, I'd really like to hear how.