Hunter Brennick AI Systems & Advisory ↗
AI Systems Orchestration
Part III · Applying And Deciding/Chapter 09
09

A Real Three-Repo Setup

A real three-repo setup where AI agents do actual work: one defines the workflows, one turns requests into plans, and one does the work itself.

9 min read3 figures
The gist
  • One repo defines the workflows. One turns requests into plans. One does the work.
  • The opportunity is not to merge them. It is to let them teach each other.
  • The best example is a gated pipeline, not a vague agent.
  • Do not mistake "agentic service" for "autonomous agent." The value is in the gates.

Three Repos, Three Jobs

These three repos map cleanly onto three layers of the bigger curriculum.

1. Defines The Workflows

This layer is good for learning what a canonical source of truth looks like. It does five things:

  • defines what workflows exist
  • generates tool-specific versions of each one so it works the same way in every AI client
  • describes what tools and context each workflow can use through machine-readable manifests
  • records run artifacts and metadata for every execution
  • validates that a generated copy hasn't drifted from its canonical source

Mental model:

defines the workflows=governs

It answers: What workflows exist? How do they show up in each AI tool? What tools are available? Where do artifacts go? What is the source of truth versus a generated copy?

A team might do well to:

  • write down a first-class convention for multi-agent run artifacts
  • build eval fixtures for common workflows such as research or ideation or review
  • keep experimental runtimes isolated until they prove real value

What not to force: don't adopt a heavyweight graph runtime just because it's interesting. Don't wire in full orchestration config until at least one or two artifact-mediated workflows have proven the shape works.

2. Turns Requests Into Plans

This layer is good for learning spec-driven development. A request becomes a written spec before anything gets built. It also shows:

  • workflow tiers and quality gates
  • artifacts as guardrails so the work isn't done until the right evidence exists
  • task completion gates tied to real checks rather than a status flag
  • telemetry that shows where work gets stuck
  • role-specific workflows for different kinds of contributors

Mental model:

turns requests into plans=bootstraps

It answers how a vague ask becomes:

  • a spec
  • a plan
  • tasks
  • an implementation
  • tests
  • a review
  • a release

The important lesson:

This layer provides the rails; the AI agents provide the engine.

That's the same idea as AI systems orchestration generally. The model is not the whole system. The system is what makes the model's work repeatable.

A team might
  • use this layer's command-to-artifact mapping as a template for the workflow layer's own artifact contracts
  • use its telemetry schema as a starting point for tracking agent runs more broadly
  • turn its real failed runs into eval fixtures

What not to force: don't try to merge this with the workflow-definition layer. It's closer to a bootstrapping and productization kit than the same thing. And don't collapse personas and workflows and runtime agents into one concept. They're related. They are not identical.

3. Does The Actual Work

This layer is good for learning what real LLM-backed services look like in production. It has:

  • pipelines with hard gates between steps
  • automation built from a mix of deterministic code and model calls
  • tool servers that expose safe and scoped access to real systems
  • production-grade concerns such as:
    • retries
    • correlation IDs
    • redaction
    • feature flags
    • observability

Mental model:

does the actual work=runs

It answers what an actual agentic service looks like once it has:

  • APIs
  • clients
  • retries
  • LLM calls
  • context lookup
  • feature flags
  • logs

The strongest example of this pattern is a support-ticket triage pipeline:

incoming ticket
  -> input processor
  -> hypothesis generator (hard gate)
  -> code-area identifier (additive context)
  -> fix recommender
  -> action generator
  -> output formatter
  -> posted back as a comment

That's a real LLM pipeline. It is not a vague "agent." It has gates, structured outputs, additive context, idempotent updates, redaction, and observability.

A REAL GATED PIPELINE ticket in input processor normalize · redact hypothesis · hard gate no hypothesis? stop here code-area identifier additive code context fix recommender smallest viable fix action generator structured next steps output formatter written for humans comment out idempotent · safe to rerun not a vague agent · structured models at every stage with correlation IDs and observability the gate is the design · work stops when the evidence is not there
FIG 09.1A real gated pipeline: structured stages, a hard gate, additive context, and an idempotent write.
A team might
  • use a pipeline like this as a study case for gated LLM workflows
  • use a code-refactoring service as a study case for model routing and deterministic-plus-LLM automation
  • use a well-scoped MCP tool server as a study case for production tool design
  • build eval suites around the triage pipeline to check whether a known issue produces the expected hypothesis and the expected fix and the expected action

What not to force: don't assume every service like this needs multi-agent orchestration. Many should stay as clean linear pipelines. And don't mistake an agentic service for an autonomous agent. The best parts here are the gates and the wrappers around the model. Unconstrained autonomy is not the point.

SERVICE OR AGENT AGENTIC SERVICE intake model stepvalidated gate out bounded · inspectable · safe to rerun structured outputs and redaction at every step every run leaves a trace AUTONOMOUS AGENT goal model decidesthe next step acts · observes repeats open ended decisions · harder to bound and audit autonomy is earned level by level · not assumed the difference is the gates many systems should stay clean pipelines · do not mistake agentic service for autonomous agent
FIG 09.2Agentic service versus autonomous agent: the difference is the gates.

The Three-Layer Map

THREE LAYERS · THREE JOBS Defines the workflows the control plane workflows · manifests · clients artifacts · validation Turns requests into plans the scaffolding kit specs · plans · tasks quality gates · telemetry Does the actual work the runtime playground services · pipelines · MCP servers retries · flags · logs workflow contracts structured artifacts and gates real eval cases lessons · traces · failures the opportunity is not to merge them · it is to let them teach each other
FIG 09.3Three layers, three jobs, and the lessons that flow between them.

A useful way to think about the three layers:

  • one is the control plane
  • one is the workflow scaffolding kit
  • one is the runtime and service playground

The opportunity isn't to merge them into one system. It's to let them teach each other.

Next chapterChapter 10 · Gaps And Project Ideas From learning map to possible builds: run ledgers, failure corpora, tool benches, model routers, promotion ladders, and orchestration labs.