Product Deep Dive · Parci

Inside Parci's Six-Agent Graph: How a Full Municipality Analysis Runs in 47 Seconds

Parci is Digiton's own proof that production AI can be fast and rigorous at the same time. Here is the architecture behind a full analysis of a Portuguese municipality in around 47 seconds.

By Brandon Da Costa, Founder, Digiton Dynamics

Why a single agent was never going to be enough

Early versions of Parci used a single large model call to analyze a municipality: read the request, retrieve some documents, write an answer. It worked for a demo and fell apart under real questions, because a single agent optimizing for one prompt tends to average across everything it is asked to do at once. Legal accuracy suffers when the same call is also trying to sound helpful and format a clean summary. Splitting the work into a graph of specialized agents was the fix.

The six agents, at a high level

Parci's graph breaks a municipality analysis into stages, each owned by an agent with a narrow job: understanding what the user is actually asking, retrieving the right legal and planning documents, cross-checking retrieved material against the specific municipality's own regulations, drafting the analysis, verifying the draft against the sources it cites, and assembling the final report in a format a non-lawyer can actually use. No single agent tries to do all of that at once, and each one can be tuned, tested and improved independently of the others.

Hybrid RAG, not a single retrieval strategy

Municipal and legal documents do not behave like a single tidy corpus. Some questions need exact keyword matching against a specific clause, others need semantic retrieval to find a conceptually related regulation phrased in completely different language. Parci runs a hybrid retrieval strategy that combines both, rather than betting everything on embeddings alone. That is a large part of how the system reaches 1,240 indexed legal citations with the precision it needs, instead of a broad but shallow index that returns plausible-sounding but wrong material.

Evaluation gates before anything ships

The part of the architecture I care about most is not visible in the final report at all: before an answer reaches a user, it passes through evaluation gates that check it against the retrieved sources, flag unsupported claims, and can reject or route a draft back for correction. This is the difference between a system that sounds confident and a system that is actually accurate. In a domain like real-estate and municipal law, a confident wrong answer is worse than no answer, so the gates are not an afterthought, they are load-bearing.

Why 47 seconds matters

Speed is not just a convenience number. A six-agent graph with hybrid retrieval and evaluation gates could easily take minutes if it ran naively in sequence, which would make it unusable for someone comparing multiple municipalities in a single session. Getting a full analysis of 308 Portuguese municipalities down to around 47 seconds meant parallelizing agents wherever their work did not depend on each other, and being deliberate about what runs sequentially versus concurrently. Fast and rigorous are usually treated as a trade-off. Getting both at once was the actual engineering problem.

Where the architecture still has trade-offs

I do not want to present this as a solved problem. A six-agent graph is more complex to operate than a single model call: more moving parts, more places a failure can hide, and a genuinely harder debugging story when something goes wrong deep in the pipeline. I accept that complexity because the alternative, a single agent trying to do everything at once, produces worse answers in a domain where wrong answers carry real cost. The trade-off is operational overhead in exchange for accuracy and speed, and for Parci's domain, that trade is worth making. It would not automatically be worth making for a lower-stakes use case where a single well-tuned agent is good enough.

What changed between the first version and now

The earliest version of this architecture ran everything sequentially, agent by agent, which was easier to build and easier to reason about, and far too slow for real use. Getting to something that runs in around 47 seconds meant going back through the graph and identifying which stages genuinely depended on each other's output and which did not, then restructuring the pipeline so independent stages run concurrently. That refactor was less about clever model prompting and more about honest systems engineering: understanding the actual dependency graph of the work, not just the conceptual one.

What this proves, beyond one product

Parci is the clearest evidence I have that a multi-agent architecture with real evaluation discipline is not just an academic idea, it is something that can run in production, at speed, under real usage. That is the same architecture pattern I bring to client work: specialized agents, hybrid retrieval grounded in the client's own documents, and evaluation gates before anything reaches a person. If you want to see how that pattern applies to a custom AI platform for your own business, let's talk about what you are trying to build.

Frequently asked questions

Related