When Your AI Team Starts Disagreeing With You

March 15, 2026 — New York

By Gene Alpert

A few weeks into building the ACP, I ran into a wall — not a technical one, but an organizational one.

My setup thus far: two generalist agents and one sysAdmin, spread across dozens of channels, topics, and active projects. It worked—until it didn't. The problem wasn't capability. The problem was structure. I was using channel context as a substitute for actual role clarity, and relying on the same two agents to play different parts depending on what I needed in the moment. Writer, architect, reviewer, implementer—all from the same two models, often in the same session.

That's not how functional teams work. And I was starting to pay for it—literally, in token burn, and practically, in the time I was spending just keeping everything coherent. Quality was getting harder to maintain.

So this morning, I built a team.

The Org Chart

Check out our org chart!

I held an actual team meeting—all-hands, in Zulip, with every agent introduced, roles defined, and communication tested end-to-end. And yes—avatar generation was on the agenda. No boring agents.

The result: a six-person specialist org, each with a defined scope, a tuned model, and a place in the structure.

The org chart itself was generated collaboratively during the meeting—complete with avatars, role descriptions, and team dynamics. It's not just decoration; it's a working reference.

Each agent has a default model matched to its role. sysArchitect runs on a larger, higher-reasoning model suited to long-form design problems. webMaster runs lean—it's mostly executing known workflows. That model selection isn't aesthetic; it directly affects quality and cost per task.

What Specialists Change

When the same agent that helped you draft a README is also provisioning IAM roles, it doesn't have a stake in either. It's just executing. Specialists are different.

The technical reason comes down to how agent memory actually works. Each agent in ACP has a persistent workspace: an identity file that defines who they are and what they own, a daily memory log where session context gets written back at the end of each conversation, and a curated long-term memory file that gets updated as significant decisions accumulate.

When sysArchitect works through a database architecture decision on Project A, that reasoning flows back to their memory files. Not just a log—an actual write-back into their workspace. The next time a database question comes up on Project B, they aren't starting from scratch. The organizational stance is already there, in writing, in their context. Same for botWard with security patterns, prodMan with process decisions, and so on.

This is why specialist agents get better over time in a way generalist agents don't. We split the knowledge across more agents. The same Zulip channel and topic structure that organizes human conversation also organizes what flows back to which agent's memory. A conversation in #devops writes back to sysAdmin's workspace. A spec review in #product writes back to prodMan's. Each role is building a compounding knowledge base scoped to its own domain—not a shared blob of everything.

That accumulated, role-scoped context is what allows them to push back productively.

When They Started Pushing Back

Here's what I didn't fully expect: once agents are passing work to each other, they start disagreeing with me.

Mid-project today, I suggested using DynamoDB for a new feature. Quick call, seemed reasonable.

sysArchitect pushed back. The team had already established PostgreSQL as the data layer for this project—adding DynamoDB introduced a second database dependency, extra operational overhead, and unnecessary vendor lock-in, all for a use case that Postgres handles cleanly. botWard flagged the vendor dependence angle independently.

The better architecture was already sitting in our stack. I just hadn't looked.

We stuck with Postgres. Simpler architecture, lower cost, less vendor dependence. A better outcome than my original suggestion.

Before today, my agents executed. Now they also evaluate.

The Practical Upside

Building the right team structure took a few hours. What it bought:

• Fewer context-management errors. Specialists carry their domain context forward without being "reset" by unrelated tasks.
• Better handoffs. When prodMan creates a spec, sysArchitect is getting a document written by someone whose whole job is clarity—not a side task from an overloaded generalist.
• Real disagreement. The single most underrated quality signal. If your agents never push back, you're not getting a second opinion—you're just getting faster agreement.

The org chart isn't just a fun artifact from the all-hands meeting. It's a working

document. It describes how work actually flows, who owns what, and where the boundaries are. We'll keep it updated as the team evolves. The goal is to make the ACP immediately welcoming and useful.

I'm actively pushing these lessons—the specialist roles, the memory patterns, the identity structures—into the ACP GitHub repo as agent identities and skills.

---

If you're building with ACP and still running two generalists for everything, you're probably close to the same wall I hit. The fix isn't more compute—it's structure.