A seven-agent coaching platform with a safety gate

The problem with one big prompt

A coaching product has to do several genuinely different jobs: understand what a user is asking for, retrieve what it already knows about them, generate a plan, schedule it, and hold a conversation about it later. The tempting shortcut is to put all of that behind one model call with a very long system prompt.

That approach degrades in a specific way. Every capability you add makes every other capability slightly worse, and you lose the ability to say which part failed when the output is wrong. There's no seam to debug at.

Splitting into specialised agents isn't about making the AI smarter. It's about making it diagnosable — giving failure a location.

The graph

Seven specialised agents sit behind an intent classifier that routes each request to the ones that should handle it — routing, generation, scheduling, coaching, retrieval and QA among them. LangGraph made the control flow an explicit graph rather than an emergent property of prompt text, which is the entire reason to use it: you can read the system's behaviour off the structure.

Memory and durable state

• Pinecone holds vector memory — the semantic recall of what a user has said and been given before, so a coaching conversation has continuity rather than restarting each session.
• Cassandra holds durable multi-session state. Vector similarity is the wrong tool for "what plan is this user actually on" — that's a fact, not a fuzzy match, and it needs to survive restarts and be exactly retrievable.

Keeping those two separate was a deliberate call. Conflating "what does the model remember" with "what is true about this account" is how agent systems start confidently contradicting their own database.

Streaming

Generation streams to the client over Server-Sent Events. In a multi-agent graph the total latency is the sum of several model calls, so the user's perception of speed depends entirely on whether they see progress. SSE rather than WebSockets because the traffic is one-directional and SSE reconnects on its own.

The QA agent

The design decision I'd defend hardest: a dedicated QA and safety-review agent gates all generated content before it reaches the user, enforced inside the orchestration graph rather than bolted on at the API edge.

Putting the gate in the graph means it cannot be bypassed by a new code path, a new client, or a future developer wiring a shortcut. If output leaves the system, it went through the gate — that's a structural guarantee, not a policy someone has to remember.

It costs latency. For a product giving people personal coaching guidance, that trade is not close.

Multi-provider by design

The platform spans Claude, OpenAI and Gemini. Different nodes in the graph have genuinely different requirements — a classifier wants to be fast and cheap, a generation step wants quality, a review step wants a model that's good at saying no. Binding the whole system to one provider would mean accepting one set of trade-offs everywhere, and it makes provider outages a total outage.

The client

The platform is consumed through a React Native client with payments and subscriptions — worth mentioning because agent systems have a habit of being demoed rather than shipped, and the constraints change once real billing is attached to real generations.

A note on ownership

I architected this system; teammates implemented portions of it. I've used "architected" and "designed" for the system-level decisions and avoided claiming the implementation wholesale. There are no published usage metrics for this platform, so there are none quoted here.