How We Built A 22-Agent Platform With Claude Code

Sparq's Solutions Consulting team used to spend 3 to 4 hours preparing for every client interaction. They dug through Salesforce notes, prior proposals, Drive docs and internal playbooks. The work was unstructured, inconsistent between people and hard to repeat.

We built the Sparq Agentic Platform to fix that, and we built it with Claude Code. This is the build log: what we made, how we configured Claude Code, what went wrong and what we would tell another team starting the same job.

What we built

Since May 2026, a small practitioner team has shipped and now operates a platform that spans four repositories (sparq-agentic-os, solutions-playbook, sparq-stories and sparq-sales-playbook). As of this writing it includes:

• 22 specialist agents behind an orchestrator
• 24 shared platform tools
• 19 scheduled autonomous jobs
• 15 portable skills
• 3 live dashboards and 2 production Slack agents
• Roughly 34,000 lines of Python across 453 commits and 159 pull requests

Sparq's revenue organization uses it daily. The team that built it also maintains it. The platform runs its inference on Amazon Bedrock. Claude Code is configured against Bedrock too, but they are different things: one is the product we ship, the other is the tool our engineers work in.

A note on what these numbers show. They measure delivery volume, and every figure comes from our GitHub history. They do not prove business impact, and we did not run the same build without Claude Code, so we cannot say what we would have produced otherwise. The 3 to 4 hour prep time is our written baseline. We have not yet published a measured after-figure, and we would rather say so than invent one.

Configuration choices that mattered

1. Methodology lives in files, not in people's heads

Fifteen skills are version-controlled and installed on each engineer's machine with one command (npm run setup-skills). The same SKILL.md file is read by an engineer working interactively and by the deployed agent running that method autonomously in production. Four skills run on both sides today: problem-zero, pipeline-insights, resourcing-notes and sparq-brand-format.

The practical result: changing how Sparq scopes a problem or structures an estimate is a pull request against one file, not a coordinated edit in two places. Without that, the consultant and the shipped agent would slowly come to disagree.

2. One CLAUDE.md per repository

Each repository carries its own CLAUDE.md at the root. They are separate codebases with different runtimes, deployment targets and audiences, so a shared parent file would have loaded irrelevant instructions into each.

The sparq-agentic-os file opens with the business problem the platform exists to solve, so every session starts from why the system exists. The sparq-sales-playbook file is written as a build guide. It records the incident history of an earlier dashboard build, including a two-frontend mistake and an AppSync decision, and what each one cost. The team was about to build a second application of the same shape. A bug log nobody reads during a build would not have protected it. A CLAUDE.md is read at the start of every session.

3. Inference inside our own AWS account

Claude Code is configured against Amazon Bedrock in us-east-1, inside Sparq's AWS account. The platform already deployed to AWS and ran on Bedrock, so pointing the build tool at the same backend gave us one inference path, one set of credentials and one bill. Model inference stays inside a boundary our security team already governs.

4. Two independent access gates

Access runs through two separately administered controls: the IAM role that grants Bedrock access, administered through our identity provider and AWS IAM, and the collaborator list on the GitHub repository. Holding the role without being a collaborator gets an engineer a tool and no codebase. Revoking either stops the work, and at offboarding the two are reconciled against each other.

The right to add new MCP connections sits with the engineers who built the connection layer. Only the engineers who built the connection layer add new MCP connections. Every new MCP server is a new data path into the system, so that call stays with the people who know it best.

5. Client data stays out of the repositories

Client data never enters the repositories. It lives in a gitignored folder, and credentials stay in a gitignored .env.local. It is gitignored, and a NOTICE.md says never to commit it. Per-user credentials live in a gitignored .env.local. The most sensitive material is absent from the working tree rather than present and restricted.

6. Pull requests for everything

solutions-playbook/CLAUDE.md states the rule: "Never commit directly to main." Context and methodology changes are reviewed the same way code is, which is why every change Claude Code contributed is attributable and reversible in GitHub.

What broke

The clearest failure we can document is a quality gate that failed open.

The Asset Council is the review stage that critiques a generated client asset before it ships. It returned ready: True on any conversion error. An asset that could not be rendered for review was treated as reviewed and passed, and nothing alerted, because to the calling code the gate had approved.

It surfaced as assets reaching the end of the pipeline with no review findings attached, which at first looked like reviewers having nothing to say. Tracing it showed the error branch returning the same success shape as the approval branch. A caller could not tell "reviewed and approved" from "could not be reviewed."

The fix was a redesign, not a patch. The review stage now uses five reviewers with deliberately incompatible mandates, run as independent concurrent calls, plus a chairman who must commit to ship or revise. Critical findings override the chairman in both directions. A reviewer that fails now counts as an abstention, not an approval. A separate document review stage rasterizes the rendered asset and critiques the image through a forced tool call, because text-level self-review cannot see a cut-off footer or an orphaned grid cell.

The lesson we took: a gate whose failure mode is approval is worse than no gate, because it manufactures confidence that nothing checked the work.

The wider record is in solutions-playbook/BUGFIX_CHECKPOINT.md: 17 incidents over four days, with root causes. That includes three regressions caused by earlier fixes and a production outage caused by shipping a fix whose prerequisite had never been met. We log our own regressions on purpose. A bug log that only lists original defects does not show how a team actually fails.

One more honest gap: we hit an MCP approval loop, where a connector kept prompting for approval on calls already approved, and we did not record it at the time. We now keep a log of Claude Code failures.

How we trained the firm

We did not write a Claude Code curriculum for the engineering team. The practice spread by apprenticeship, with people working next to someone already using the tool and learning the rest from repositories that carry the methodology in files the tool reads. That works at our team's size and would not scale past it.

What we did run firm-wide was Sparq Flight School, an internal Claude certification platform with two tracks and 300 practice questions grounded in Anthropic's exam guides, open to every employee. A certification boot camp ran on top of it. Sparq went from 36 Claude certifications on Aug 20, 2026 to 117 on Sept 23, 2026, roughly one in five employees, and passed its goal of 100 on Sept 15.

Flight School and Pitch Trainer, a client pitch simulator, are themselves internal applications specced in Claude Cowork and built in Claude Code.

What we would tell another team

• Put build context where the tool reads it, not in a wiki.
• Write incident history into CLAUDE.md before you build the next thing of the same shape.
• Keep one copy of each method, shared by people and agents.
• Treat a gate that fails open as a critical bug.
• Measure early. We did not instrument adoption, and that is the weakest part of our own story.
• Write the support runbook before the practice leaves the team that built it.

If your team is weighing a Claude Code rollout or an agentic build, talk to Sparq about the Claude implementation work.