Building a 14-Agent Internal Operations Platform

Fourteen Workflows, One Broken Pattern

I architected and built an internal platform to support the sales and delivery workflows of an enterprise services organization I was part of - the kind of work that exists behind almost every services business and gets almost none of the engineering investment that customer-facing product gets. Proposal responses. Account research ahead of a pursuit. Briefing preparation before a client meeting. Individually, each of these looked like a different problem assigned to a different team. Collectively, they were the same problem wearing fourteen different outfits: someone needed to synthesize a large volume of unstructured information into a specific, time-boxed output, under deadline pressure, for an audience that was going to judge the output on quality of judgment as much as accuracy of fact.

Fourteen workflows, fourteen teams, fourteen ad hoc processes - most of them a mix of manual research, templated documents, and institutional knowledge that lived in a handful of people's heads. None of it was built to scale, and all of it broke the same way under deadline pressure: the people doing it ran out of hours before they ran out of things they needed to read.

Why One Agent Does Not Scale to Fourteen Jobs

The naive version of this project is a single assistant with a good prompt, pointed at whatever the task of the week happens to be. That does not survive contact with fourteen genuinely different jobs. Researching an account ahead of a sales pursuit requires synthesizing public financial disclosures, news, and relationship history into a point of view on where an opportunity might exist. Responding to a formal proposal requires parsing a structured requirements document, mapping each requirement to prior evidence of capability, and producing compliant, specific, non-generic answers. Preparing a briefing for an executive meeting requires an entirely different register - shorter, more opinionated, structured around decisions rather than exhaustive coverage.

I built fourteen agents, each scoped to one job, rather than one agent asked to be flexible across fourteen jobs. Each agent has its own retrieval sources, its own output template, and its own definition of what a good result looks like, coordinated through a shared orchestration and knowledge layer so that research done for one workflow - a piece of account intelligence gathered for a pursuit, say - was available to any other agent that could use it, rather than being re-gathered from scratch every time.

Architecture: Model-Provider Integration Across OpenAI, Anthropic, and AWS

The platform integrates models from OpenAI, Anthropic, and AWS rather than standardizing on a single provider, and that was a deliberate choice rather than an accident of procurement. Different agents have different requirements - long-context document synthesis, structured extraction against a rigid schema, conversational tone-matching for briefing documents - and no single model family was the best fit for all fourteen jobs at once. A routing layer sits between the agents and the underlying models, so that swapping or upgrading a model for one workflow does not require re-architecting the others.

This multi-provider approach cost more up front, in the sense that it meant maintaining integration and evaluation work against three separate ecosystems instead of one. It paid that cost back the first time one provider's model handled a task class meaningfully better than another's, because switching cost was a configuration change rather than a rebuild.

The Agent That Almost Died: The RFP Responder

One of the fourteen - the agent that drafts first-pass responses to formal proposal requests - is the one most people outside the platform ever heard about, because it eventually reached adoption well beyond the team it was originally built for. It did not start that way.

The first version was built, reasonably, around the demo: feed it a sample RFP, watch it generate a complete, well-structured draft response in minutes instead of days. It demoed extremely well. It also sat mostly unused for weeks after launch, because the daily reality of responding to a proposal is not "generate one clean draft" - it is "generate a draft, then have several people with different expertise argue about specific sections, then revise under a deadline, then have someone senior sign off on claims they are personally accountable for." The tool was built for the moment that impresses an audience, not the moment that actually consumes someone's week.

The fix was not a better model. It was re-sequencing the entire workflow around trust and human-in-the-loop review rather than around draft generation. We rebuilt the interaction so that every claim the agent generated was traceable to a specific prior proposal or capability statement it had pulled from, editable inline by whoever owned that section, and explicitly flagged wherever the agent had synthesized language rather than pulled it from a verified source. The agent stopped trying to be the author of the response and became the first-pass drafter that subject matter experts trusted enough to edit rather than discard and rewrite from scratch.

Adoption after that redesign spread well past the original team, to essentially every function that touches a formal proposal response. The lesson was not about the model. It was about who the tool actually had to convince, and it was not the person watching the demo.

Results

Fourteen agents in production, each scoped to a distinct sales or delivery workflow, coordinated through a shared orchestration and knowledge layer.
Three model providers integrated - OpenAI, Anthropic, and AWS - routed per-workflow rather than standardized on one, so each job runs on the model best suited to it.
The RFP response agent reached adoption well beyond its original team, becoming the one component of the platform used by essentially every function that produces a formal proposal response.

What I Would Do Differently

I would build the trust and traceability layer into the first version of every agent, not just the one that stalled and forced the lesson. The RFP responder taught me the pattern - that adoption depends on visible, editable, source-traceable output more than it depends on draft quality - after the fact, and I retrofitted several of the other thirteen agents once I understood it. Retrofitting trust architecture into a live agent that people have already half-abandoned is a much harder sell than building it in from the start, even when you can prove the new version is better.

I would also spend more time up front with the actual daily user of each workflow rather than the stakeholder who requested it. The RFP responder's early version was scoped in conversations with people who wanted a good demo. The people who were going to use it every week were not in that room, and their absence is exactly why the first version optimized for the wrong moment.

The Broader Pattern: Adoption Before Automation

Technical completeness is not the same thing as product-market fit, and nowhere is that gap more visible than in internal tooling, where there is no external market to force the correction. A tool that works, that generates genuinely good output, that demos beautifully, can still fail if it was built for the moment someone evaluates it rather than the moment someone has to actually rely on it under deadline pressure with their name on the outcome.

The multi-agent architecture and the multi-provider model integration were both necessary. Neither was sufficient. What made the difference between an agent that sat unused and one that reached adoption across an entire function was whether the people using it could see why it said what it said, and whether they trusted it enough to build on top of its output instead of starting over. That is a design question, not a model question, and it is the one I now ask first on every agentic system I build, not the one I get around to after the demo goes well.