Agents

Multi-agent content platform (planner → critic loop)

Calling something multi-agent usually means a prompt was split into four prompts. What makes this a graph is the edge that goes backwards: the critic can reject work and send it back to be done again.

reference.pdfslides · quizper-instructor
tone & domain
topology
cyclic agent graph
roles
planner · researcher · writer · critic
orchestration
async, via Make.com
tenancy
concurrent multi-tenant

A graph, not a prompt chain

A prompt chain is a pipeline with the steps named after job titles. It runs planner, then researcher, then writer, once each, in that order, and whatever comes out the far end is the answer. If the draft is weak, nothing in the system is in a position to notice, because by the time the weakness exists every step that could have acted on it has already finished.

This is built in LangGraph as an actual graph, which means conditional edges and cycles. The critic's rejection is not a log line; it is an edge that routes the work back into the graph for another pass. That single backwards edge is the entire difference between a system that produces a first draft and a system that produces a draft something has approved.

What each agent is for

The planner takes the brief and splits it — deciding what the piece needs to cover before anyone starts writing, so that structure is a decision rather than an accident of generation order.

The researcher and writer both work against retrieved source material rather than against the model's own memory. This is the same instinct as the retrieval work: an agent writing from parametric knowledge is an agent with no way to be checked, and grounding the writing in retrieved sources is what makes the critic's job possible at all.

The critic evaluates the result against the brief and the sources, and rejects output that does not hold up. Its verdict is a routing decision, not advice. Weak work goes back around.

Making it survive production

An agent graph in a notebook and an agent graph serving customers are different systems. Steps are retryable, because a graph with four model calls per pass and a cycle on top of that will hit a transient failure eventually, and the correct response to one bad API call is not to discard the whole run.

Long-running work is orchestrated asynchronously through Make.com rather than held open on a request. A multi-pass agent graph does not fit inside a request-response cycle, and pretending otherwise is how these systems end up timing out under exactly the load they were built for.

Sessions run concurrently and multi-tenant on Google Cloud, with FastAPI services behind a Next.js interface. GPT-4o and Claude are both in the graph — different roles have genuinely different demands, and there is no reason a critic and a writer have to be the same model.

Stack

LangGraphGPT-4oClaudeFastAPINext.jsMake.com