We have four ideas from the previous post. The natural instinct: build four separate applications, each an independent project with its own repo, its own webhook, its own database. That’s not a good idea, though — and the AI-agent developer community in 2026 arrives at the same conclusion, for the same reason the industry advises against premature decomposition into microservices.

What our four ideas have in common

All four share an identical skeleton: webhook → decision graph → state persisted → human approves → action on repo/knowledge base. Only the domain logic in the middle differs — prompts, classification, the specific integration.

Picture two ways of building this. In Variant A, each of the four applications — Clarify, Patch, Learn, Triage — gets its own webhook intake, its own deduplication logic, its own approval mechanism, and its own audit log. In Variant B, there’s one shared core handling webhook intake, deduplication, approval, audit, and the knowledge base — and each application is just its own piece of domain logic plugged into that core.

Variant A · four separate apps Clarify webhook · dedup · approval · audit Patch webhook · dedup · approval · audit Learn webhook · dedup · approval · audit Triage webhook · dedup · approval · audit Variant B · shared core + workflows Clarify logic Patch logic Learn logic Triage logic Shared core webhook · dedup · approval · audit · knowledge base

In Variant A, the boilerplate boxes (webhook intake, approval mechanism, guardrails, audit log) get written four times — and that’s duplication of something that should, by nature, be consistent: governance over what an agent can do without a human shouldn’t differ between applications without a clear reason.

What the community says

  • „Don’t decompose too early.” This is literally the same lesson the industry took from the microservices era, now repeated for agents. As one write-up on multi-agent architecture put it: multi-agent systems go through the same maturity curve as microservices — monolith → decomposition euphoria → „oh no, distributed systems are hard” → settling on practical boundaries. Teams want to split everything into many specialized agents when a single good orchestrator with proper tool selection handles 90% of the cases.
  • Hub-and-spoke as the dominant production pattern. According to practitioners writing up their deployments (honest caveat: these are engineering blogs, not peer-reviewed research), production multi-agent systems mostly use an orchestrator + workers model — a top-level agent decomposes the task, specialized agents execute — rather than a swarm of independent micro-agents, even though academic papers on swarm architectures describe more elaborate structures.
  • A centralized gateway as the approval choke point. Write-ups on this kind of infrastructure put it plainly: „tools or actions can be marked as requires human approval,” and Pinterest mandates human-in-the-loop for all sensitive tool operations centrally, through one gateway — not separately in each application.
  • A monorepo makes managing agents easier. Open standards like AGENTS.md assume one canonical set of conventions and context at the top of the repo, with clear subdivisions and ownership — instead of scattered repos with duplicated (and eventually diverging) decisions.

Trade-off: hub-and-spoke and a centralized gateway mean one point of responsibility — if that gateway goes down or has a bug in its access policy, it affects all four workflows at once, not just one. We accept a larger blast radius for a single core failure, in exchange for consistent, auditable governance. That’s a deliberate trade, not an oversight.

Our decision

One platform core, many pluggable workflows. Each of the four ideas becomes a workflow (a LangGraph.js graph) registered in a shared core — not a separate application built from scratch. The details of that core (components, the contract every new workflow must satisfy) are the subject of the next post.

A critical look — before we start designing

No architectural decision is free, so before we move on, let’s honestly name the risks:

  • The platform core is a big project with zero user-facing value until it exists — a real risk that we build the foundation before any workflow delivers a first result. This exact risk is why we later deliberately start with one application without the full core, not the other way around.
  • Human-in-the-loop can erode — at real volume, people start clicking „approve” without reading (rubber-stamping), turning the safeguard into theater. None of our design docs measure this yet — it’s an open problem, not a solved one.
  • Opportunity cost — the tools from the previous post (Copilot coding agent, Sentry Seer, Intercom Fin) already do 70-80% of what we’re planning; we need an explicit justification for building instead of buying, per workflow, not as one blanket statement.
  • No success metrics or prompt evaluation yet — without a golden dataset with expected output, every prompt change is a shot in the dark.

We’re naming these risks now, deliberately, and we’ll return to them before we start coding the first application.

What’s next

Since the decision is one core plus pluggable workflows, the next post lays out exactly what that core is made of, what contract every workflow must satisfy, and how we split the knowledge base across different levels of data sensitivity.

Bibliography

Categorized in:

AISDLC

Tagged in: