What We Learned Running 5 Agent Pods on a 6-Platform Engagement

We didn't plan to run five agent pods at once. The engagement started with two - Code and QA - on the Drupal side of the stack. Within three weeks, the client's platform complexity made it obvious that two pods operating in isolation were creating more coordination overhead than they were saving.

The engagement involved a global certification organization rebuilding their digital platform across six interconnected systems: Drupal for the web experience layer, Salesforce for member management, HubSpot for marketing automation, AWS for infrastructure, plus two additional service integrations. The team had tried running AI coding assistants before. They'd gotten faster individual outputs, but the cross-platform work - where a change in the Salesforce data model affected the Drupal rendering layer which affected the HubSpot personalization logic - was still entirely manual.

That's the gap we were trying to close. Not faster outputs on each platform. Faster *connected* outputs across all of them.

The five pods

Each agent pod is a specialist. Not a generalist model pointed at a codebase - a purpose-built agent with a constrained scope.

Code Agent handled implementation across the Drupal and Salesforce layers. Module scaffolding, API integration patterns, migration scripts. It operated in the codebase daily but never shipped without operator review.

QA Agent ran test generation, regression detection, and cross-platform validation. The critical part: it could trace a change in one platform to its expected impact on another and flag when the test coverage didn't match.

Ops Agent managed deployment orchestration, environment provisioning, and the operational glue between six platforms that each had their own release cadence. When the Drupal deploy needed to wait for the Salesforce schema migration to propagate, the Ops Agent tracked that dependency graph.

Comms Agent handled internal delivery communication - sprint summaries, stakeholder updates, risk flags. Not glamorous, but on a six-platform engagement with multiple workstreams, the coordination overhead was real and growing.

Context Agent was the one that changed everything. It ingested from the client's Jira, Slack, GitHub, Zoom, Datadog, and Confluence - building a living knowledge graph that every other agent could query. This is the meta-agent: it doesn't execute delivery tasks, it feeds the intelligence layer that makes every other agent smarter. When the Code Agent was working on a Drupal module, it didn't just have the codebase. It had the Jira ticket history, the Slack thread where the architect explained the constraint, and the Confluence page where the original decision was documented.

What actually compounded

The compounding effect wasn't theoretical. Here's a concrete example.

The QA Agent flagged a regression in the HubSpot personalization layer. The root cause wasn't in HubSpot - it was a Salesforce field mapping change from two sprints earlier. Without shared context, a human would have spent half a day tracing that dependency. The QA Agent traced it in minutes because the Context Agent had already mapped the relationship between the Salesforce schema change and its downstream consumers.

That pattern repeated dozens of times. A change in one system creating an unexpected ripple in another - caught faster because the agents shared a knowledge graph instead of operating in silos.

The throughput improvement was 3-4x across the engagement, measured against the team's pre-agent velocity on comparable work. Cost per feature dropped 35% - not because the agents were cheap, but because the Context Engine understood how all six platforms interacted, eliminating the cross-platform discovery work that used to eat sprint capacity. But the number that mattered most to the client wasn't throughput - it was the reduction in cross-platform integration defects. Those bugs are expensive. They surface late. They erode trust. The shared context layer caught them early.

What broke

It wasn't smooth from day one. Three things went wrong that are worth flagging.

First, context ingestion was noisier than expected. The client's Slack had years of channels, and the Context Agent initially surfaced outdated architectural decisions as current. We had to build recency weighting and explicit deprecation markers into the knowledge graph. That took a week we hadn't planned for.

Second, the Ops Agent's dependency tracking assumed cleaner release cadences than reality. Two of the six platforms had irregular deploy windows controlled by external vendors. The agent modeled dependencies assuming predictable schedules. We had to add manual override checkpoints - the operator could tell the Ops Agent "this deploy is blocked externally, hold the downstream chain."

Third, operator cognitive load in the first two weeks was high. Five agents producing output across six platforms means a lot of review surface. We ended up staggering the pod activation - Code and QA first, then Context, then Ops and Comms - rather than lighting everything up at once. That sequencing should have been the plan from the start.

What you can take from this

If you're running AI agents on a complex, multi-platform engagement, the single highest-leverage investment is shared context. Agents operating in silos will produce faster individual outputs and more integration defects. The context layer is what turns five independent accelerators into a system.

Start with fewer pods than you think you need. Activate them sequentially, not simultaneously. And budget real time for context calibration - the knowledge graph doesn't work on day one. It works on day fifteen, and then it compounds.