Stage Agents and Tools

P Each stage selects the methods and agent roles needed for its actual case. Definitions live on the module subpages linked below. The Common catalogue contains shared definitions only; the module index contains references, not a second set of descriptions.

P A skill is an LLM-guided domain procedure. Its optional executable helpers are runnable source/binaries. Runtime/connector access and parent/agent-call protocols are not additional learned skills or fictional tools.

P Intake is polling/push and durable event handling; Support root then classifies and routes. Assessment & Offers clarifies, assesses effort, prepares an offer, obtains the customer decision and communicates it. Core Development is an offer type and has no code pipeline.

P Agents consult one another in either direction through the runtime communication protocol. A reply is evidence, not scope or authority. Experience strategies define case/domain retrieval and canonical memory indexing.

P What the v1 memory could still become — every candidate tool, skill and article with its seeds, owner and evidence — is inventoried on Memory-derived capabilities; the board of the detailed view lists a profile's candidates beside its published methods.

Support

Data & Manipulation

Configuration

Customer-specific development

Assessment & Offers

Composition and implementation checks

P Common catalogue holds shared definitions only. Module-owned agents and procedures are documented on module subpages; the central index links to them.

P A skill is the complete LLM-guided procedure. A tool is its versioned executable source/binary helper. Runtime/connector verbs and agent protocols are not learned tool packages.

P Intake is poll/push and durable event handling, not an LLM agent. Support root receives its arrival and can use broader case, experience and agent-call capabilities.

P Experience retrieval selects a domain/purpose strategy. Classification uses current cases and routing summaries; domain work uses detailed patterns and current applicability checks. Owned memory is indexed, not copied into every domain.

P Normalization establishes source meaning through LLM interpretation and semantic review. The actual Python validator only checks supplied-model consistency; it cannot prove document understanding.

P Common executors, curators and validators preserve their authority/context boundaries. An available binary or accepted offer never grants implementation rights.

P Assessment & Offers is an embedded working graph in the Support case: clarify request, assess effort, prepare offer, obtain customer decision, communicate it. Core Development is an offer type, never a code pipeline.

P Support root retains classification and routing as checkpoints of one task; a classification adviser is optional. Unknown symptom domains use one evidence-led general investigator, while known domains can investigate afresh with their existing profile.

P Configuration domain planners carry clarification, plan synthesis and execution coordination. ABACUS, IPAL, Offer and Serdica have their own independent validators; joint/target proof uses the integration validator. Necessary original requirements and evidence are always retained.

P Data S8 is attached only to Data after the verified result. Configuration release and Source S6-S9 prepare and confirm scripts/API/SQL, execute and verify the target as part of requested delivery.

P Assessment clarification and investigation share one assessor task; offer preparation belongs to a dedicated agent after assessment. The coordinator owns proposal revision and customer decision, with no implementation authority.

P Every model profile names the eval set that proves it; the set is declared by its module manifest or by platform-profiles.json, and a profile publishes only when it is green.

P Executable helpers with real source in the workspace — the channel CLIs, aisa-blob, the person-policies SQL template, the vehicle comparator, the product-model validator — are catalogued under the methods that call them; every other helper stays a proposal in the operation inventory until its input/output and falsifying cases exist.

P Every stage box is the stage agent: its qualified name, description, consult line, utility agents, shared services and gates. A consult asks a domain's owning agent for knowledge; a change in another module is a handover the root raises at Hd.

P Producers verify and test their own result; the independent agent that checks that result against the human-supplied scope is a validator. The words are used exactly so: verification and test belong to the producer, validation to the isolated checker.

P The independent reading at Configuration S1 is a provisioning applied per section of the insurer's material, not a tariff speciality: the same denied-context profile reads rates, covers and definitions, factors and value lists, and package rules, in one pass, and reconciles them against each other. A value list can never be reconstructed from a rate grid, so the sections outside the tariff need the second reading exactly as much as the tariff does.

P Configuration has no implementer profile and Development does, and the difference is the domain, not an oversight: Development has a placement decision that precedes any code and authors its change in a worktree, so planner and implementer are different jobs; Configuration's target system is its domain and its apply path is packet → the target's deterministic effect applier, where a second interpreting profile would sit between an approved packet and the target.

P Implementation's stage profile is the generic source.implementer. The declared sources — backend, UI, stored code, and whatever else a customer plug-in declares — are siblings selected per case; no repository is the default.

P The write auditor and the write executor were one component described as two: the auditor's four checks are a bounded set of queries and a template comparison against the same connector the apply uses, and it was never allowed to repair what it checked. They are now one deterministic common.effect-applier, and it is instantiated per declared target: a system's own configuration endpoint, a parameterised statement, a publication sequence, a user-interface action and an assigned person are different media with different evidence and different recovery, and none of that is shareable. What is shared is the four checks, the template rendering, the journal and the rule that a tool cannot grant itself permission.

P Clarification is not a step of the desk's triage: the stage that discovers it cannot start is the one that must ask. The agent is therefore optional on the first stage of every lane — Data solution take, Configuration normalization, Development planning, Assessment effort — and it carries H6 and the send gate there. Assessment & Offers loses its separate clarify stage: one assessor task already spanned clarification and assessment, so the stage was a second name for the same work.

P common.effect-applier and source.test_runner were catalogued as agents while their profiles declare execution_kind=deterministic. They are mechanisms: they hold a task and a grant, but no prompt, no model route, no eval set and no memory. That distinction is what a reader needs — an agent can be argued with, a mechanism can only be satisfied — and it is now the same word in the catalogue, the drawing and the board.

P Development had a Test stage of its own while the platform's rule is that a producer verifies and tests its own result (D180). It carried no gate, its owner was deterministic, and its only edge on failure returned to Implementation — a loop, not a stage. The declared build and test set now runs inside Implementation through source.test_runner, whose independence is provisioning, not position: no model writes that record. The stage that follows is Validation, the isolated check against the approved brief, and its corrections return to Implementation.

P The effect step is one procedure over five media, and only two of them are alike: an endpoint call and a statement return their own evidence, a publication sequence proves itself by the version that actually serves, and a user-interface action and an assigned person cannot be caused by the platform at all — they are assigned and then measured. Calling all five 'apply' is right only because Application is defined that way throughout: executing permitted steps or coordinating an assigned external action. What must never blur is the evidence rule: a person's report is not proof that an effect landed.

P The class 'code' was crossing two axes at once — it held the runtime's own actors and the helpers a method calls, which have nothing in common except the absence of a model. The vocabulary is a 2×2: does it hold a task, and does a model run it. Actor plus model is an agent; actor plus code is a mechanism; procedure plus model is a method; procedure plus code is a helper. Shape carries the first axis on the map, colour the second.

P Applying an accepted result to a live system is not a template renderer. Which objects take the system's own endpoint and which take a statement, the order across targets, the conventions that decide whether a write is accepted at all, what a 450 means against what a timeout means, what proves the effect is there, and how to reconcile a partial outcome — that is domain knowledge of the target systems, applied case by case. So common.effect-applier is an agent, holding the write-envelope knowledge and following a published procedure for the checks; it is simply never the agent that authored the result. Authority is not its good behaviour: grants, shapes and decisions are enforced by the runtime, which refuses before contact. The intake and the test runner, by contrast, really are code with a contract — tools.

Authoring sources

Map renderer · Build entry · Catalogue renderer · Source validator.