A complex use case is not one build — it's a sequence.

Write the use case as one decidable sentence

Force the ambition into this shape: "Given [these inputs], decide [this], so that [this person] can [do this next]." If the sentence needs an "and", you have two use cases. Pick the one whose answer someone is waiting on, and park the other.

Good: "Given a supplier's contract and open incidents, decide whether renewal needs legal review, so the buyer can route it before the deadline." Bad: "Modernise supplier management."

Cut a vertical slice, not a horizontal layer

Take one document type, one queue, one country, one product line — and go all the way through to the person who acts on the output. A slice that stops at "the model produced text" proves nothing; a slice that changes what one team does on Monday proves everything. Horizontal work (ingest all data, connect all systems) looks like progress and delivers no verdict.

Build the evaluation set before the agent

Collect real historical cases and their known-good outputs, and register them as use cases in the evaluation service. Runs are then scored on reference metrics (BLEU, ROUGE, METEOR, BERTScore) alongside judged dimensions — actionability, clarity and structure, domain specificity, depth of analysis — and an overall score with written expert analysis.

# 1. register the cases
POST /use-cases          { "name": "...", "input": "...", "expected": "..." }

# 2. run the current configuration against them
POST /run-tests

# 3. score the results
POST /run-evaluation
GET  /results            # per-case scores + expert_analysis

This is the step teams skip, and it is the step that makes every later argument short: quality stops being an opinion and becomes a number attached to a version.

Configure the domain instead of over-writing prompts

Create a domain for the slice and put the durable behaviour there rather than in a prompt somebody will copy-paste into three agents. A domain carries its own context instructions, preferred output formats, tool preferences, model hints, and a regulated flag that forces routing to approved models only. Prompts should hold the task; the domain holds the rules of the house.

Make the inputs reachable before you orchestrate

List every input the decidable sentence names, then find the cheapest legitimate path to each: an existing connector, a vector index over the document set, or one of your own endpoints registered as an HTTP tool. Orchestration cannot compensate for an input the platform cannot see, and this inventory is usually where the real timeline lives.

Let intent decomposition draft version 0.1

Send the description and let the platform propose the graph. You get a validated NetworkSpec, canvas-ready nodes and connections, any validation notes, and metadata on how each node was assigned an agent.

curl -X POST "$V3/intent/decompose" \
  -H "Content-Type: application/json" \
  -d '{
    "task_description": "Given a supplier contract and open incidents, decide whether renewal needs legal review.",
    "domain_id": "procurement",
    "agent_selection_mode": "hybrid",
    "max_subtasks": 6
  }'

hybrid reuses matching agents from the hub and creates on-the-fly agents only where nothing fits. Save the result with POST /networks?bump=minor so the version history starts at the first draft.

Execute once, then read the record — not the answer

Start a run, watch events live, and open the per-node outputs. The final text tells you whether it worked; the node record tells you why, and mediocre results almost always localise to one step — a retrieval that came back empty, a plan that split the task on the wrong seam.

POST /networks/<network_id>/execute   -> { "run_id": "..." }
GET  /runs/<run_id>                    # run record
GET  /runs/<run_id>/nodes/<node_id>    # what that step actually produced
WS   /runs/<run_id>/events             # live execution events

Improve by version, then widen scope deliberately

Fetch the hints a run produced and apply them as a derived network rather than editing the live one, so v0.1 and v0.2 can be scored against the same evaluation set. Only after the owner signs off on the score should you widen — and before you do, write the policy contract down: approved models for regulated domains, tool allow-lists, whether external APIs are permitted at all.

GET  /runs/<run_id>/hints
POST /runs/<run_id>/apply_hints   -d '{ "mode": "new_network" }'

With runs accumulating, the learning layer starts contributing too — model routing, tool selection, and agent selection all improve from observed outcomes rather than from a rules file you maintain.