Agents

Purpose

This page defines agent profiles, isolation and the communication protocol. Common agents and methods owns shared definitions. Each module head links to its own agent/method subpage: Support Root, Data & Manipulation, Configuration, Development, and Assessment & Offers. There is no second global copy of module definitions. Intake is a poll/push mechanism, not an LLM profile.

Conventions: Boots from = own AGENTS.md index + task prompt, with compatible skill/tool contracts selected on demand; Writes = the explicit owned-domain set, with proposals for other owners; Tools = permitted control calls, published source/binary tool bindings and scoped connector operations; In / Out = typed messages and their referenced artefacts; Escalates = parent, after the configured failed-attempt limit. Memory, skills and tools defines their distinct roles in learning.

P The complete stage-to-agent, skill and tool inventory also drives the detailed homepage SVG. Core Development is an offer type in Assessment & Offers; effort assessment and customer approval do not create a Source pipeline. Every working stage names its responsible profile; identical stage numbers in different modules are different stage identities.

0. The profile — what one node is

"Profiled agents" is the noun the whole platform is built on. A profile makes instructions, capabilities and dependencies explicit and repeatable; it does not guarantee identical LLM judgements. Pinned executable tools make their mechanical segments reproducible, while evaluation measures the remaining variation. Changing a prompt, skill or tool is a versioned, testable event.

This document defines the profile. Everything else in the wiki that says "profiled" means an instance of this.

0.1 The fields

P Profiles declare execution_kind=llm or deterministic. Model profiles bind a published prompt and route; deterministic profiles bind a registered handler key and framework version, and use no invented model route. The task/ledger identity is common to both (Model Execution).

P A profile is a versioned row set in SRD_SUPPORT (Architecture § 1) — data, not code, not an enum.

P Three things are distinct and must not be conflated: the profile (this definition, versioned), the instance (one running agent in one case, which the ledger identifies), and the memory domain (a knowledge namespace). "Agent == memory domain" (Agents Memory) means one domain has exactly one writing profile — not that profile and domain are the same object. Several instances of one profile run at once; a profile writes only its explicitly owned domains; each domain has one canonical owning profile. What any other profile produces for a domain is never a write but a proposal — case-local first, confirmed into the shared tree by the owning profile (Agents Memory § 2, Agents Memory § 7.4b).

0.7 Agent, skill, tool

P Three words, and every node on the detailed view is one of them.

P One class, three roles, and a namespace. Every agent is the same blue; its role is a tone (D199, D200). An orchestration agent — the module root of § 5b, and the Support root that owns Stage 1 — owns whether and who: deep blue. A stage agent owns how: the pale stage box. A utility agent is called for one bounded question and returns: a white box inside the stage. The profile variants a stage declares (profile_variants in the module manifest) — Investigation picks one investigator by symptom domain, Implementation runs one implementer per declared source the change touches — are white boxes too, under a caption that says the case selects them. A shared agent is a utility agent in the common. namespace — the same white box, grouped under Shared (common.) it also calls in every stage that calls it: common.communicator, common.db-extractor — and a shared skill or shared tool is the same fact one class over: common.skill.validation, common.db-prober, common.effect-applier, common.tool.aisa-jira.

P The tools, in full. Called by a skill: common.tool.aisa-blob · common.tool.aisa-hdesk · common.tool.aisa-jira · common.tool.aisa-mail · configuration.tool.product-validator · data.tool.car-compare-sql · data.tool.person-policies-sql. Run by the platform itself: platform.intake · source.test_runner — platform.intake validates a source, deduplicates the revision, persists the arrival and starts or resumes the case; source.test_runner runs the declared build/test set on the pinned build state and records what actually ran. Both hold their task in the ledger like anything else; what makes them tools is that there is no prompt, no model route and no eval set.

P Applying a result, and measuring a database, are skills — procedures the owning stage agent runs inside its own task (decision Vladimir, 10.09.2026 — D200, which reverses D196's reading of the applier as an agent). common.effect-applier is the published procedure for landing an accepted result on IPAL, ABACUS, INSIS or a customer surface: first the four checks — exactness, boundedness, reversibility, scope — then the landing, which needs the knowledge of those systems case by case: which objects take the system's own configuration endpoint and which take a parameterised statement (Write envelopes § 1); the order the calls must go in across more than one system; the conventions that decide whether a write is accepted at all — every primary key named id, every column sent, the payload wrapped in content; the decode of what a failure means, where a 450 says fix the data and a timeout says fix the shape; what actually proves the effect is there, which for a rating version is the version that prices and never the compile; and how to reconcile a partial or unknown outcome. None of that is a template render, and none of it is a separate actor: the agent that owns the effectful stage runs it — support.application, support.recovery, the four configuration builders, configuration.deployer, source.deployer, and support.root at closure — so no applier task, profile or eval set exists.

Two things keep that safe, and neither is the agent's good behaviour: the procedure never repairs the packet it checks — a failing item is named and returned, never corrected — and the agent asks, the runtime decides: grants, gate decisions, shapes and ceilings are enforced by the authority service and the connector scopes, which refuse an operation outside them before contact (Gating § 6, § 9). common.db-prober is the same kind of thing one step earlier: an intent-blind measurement — constraint, type, distribution, counts — run by the agent that needs it and told nothing about the value it hopes for.

P There is no fourth mark for "shared". A definition in the common. namespace is one definition every module calls, rather than a copy per module — the namespace says so, and the map needs no glyph for it. It says nothing about class: there are common agents (common.communicator, common.db-extractor, common.experience-curator), common skills (common.skill.validation, common.db-prober, common.effect-applier) and common tools (common.tool.aisa-jira). It says nothing about state either: each call is still its own scoped task, and a reused profile never sees another case's transcript, grants or task state (§ 0.2).

P Two reading rules make the rest follow. A box that shows a profile id is an actor — an agent, or a tool the platform runs; a box without one is a note, a procedure caption or a workflow step, and nothing initialises for it. And a node's own line says what it is — agent · runs a model, or tool · code with a contract · no model — while the legend's miniatures at its top right count what it runs: a green pill with the number of skills, a slate square with the number of tools it reaches, directly or through those skills. The names are in the brief below the diagram, one click away, because the map answers who acts and the brief answers with what.

P The remaining marks are not capabilities at all: an amber diamond is a decision gate — a person answers (Gating) — and a purple droplet is a precipitation event, which is asynchronous and holds nothing open (Stage Precipitation).

0.2 Isolation is provisioning

P Tool-aware working behaviour. Before repeating a mechanical step, inspect the owned/domain tool index and select the compatible published tool. Use a declared automated segment instead of an LLM call per record or substep. Return unsupported variants as findings. When repeated reasoning, latency, usage or inconsistent output reveals an automation opportunity, include it in the result for the domain owner: existing tool to extend or bounded new operation, inputs, expected proof and source cases. The author can delegate implementation to an existing code-capable task; no new permanent agent profile is needed. Tools as retained learning defines the complete lifecycle.

F The proven mechanism is denied context, not an instruction to ignore something: the source analyst's scope contains no database connector, so storage cannot bend its reading of a tariff; the grader sees two artefacts and no provenance, so it grades output rather than remembered reasoning [F: the PC sub-agents].

P Producers verify; validators validate. A stage agent tests and verifies its own result — its assertions, the stage skill, the deterministic test runner, the runtime check of what serves. The isolated agent that checks that result against the human-supplied scope — the accepted specification, the approved plan or brief, the confirmed solution packet — is a validator, never a second producer: the mechanism validator, the solution and outcome validators, the four configuration domain validators, the integration validator, the source validator. The words are used exactly so throughout this wiki: verification and test belong to the producer, validation to the isolated checker.

P In the C# host this is an explicit task context/tool facade: standard DI scopes do not remove parent registrations; the interpreter exposes only the declared readers/tools (Architecture § 1). A profile cannot widen its own grants; widening is a gate decision.

Standing isolated profiles: source analyst (no DB), estate prober (no product intent — it returns counts, never advice, and keeps permitted distinct from used), effect applier (no author transcript and no reasoning — it checks that a write packet is exact, bounded and revertable before any gate sees it, Gating § 6), validator (no author transcript — it re-derives the mechanism from evidence alone), reviewer (no author reasoning/transcript; relevant requirements and evidence retained; its checklist is data: test placement, i18n set, csproj bumps, appsettings hunks, cross-repo contract, lineage of the change — Customer-Specific Development Module § 5 G6), grader (no provenance).

0.3 Model route and the data boundary

P The route a profile declares is validated against its module's allowed provider class at governed route selection (Platform Details PG-7). Not at adapter construction: F the inspected predecessor registers singleton clients with one endpoint per kind (verified 01.09.2026). P The owned host keys clients by endpoint/credential configuration; residency is validated for the selected deployment on every route decision (Model Execution § 5).

The boundary is therefore code at the route selector — which already resolves a versioned route from DB rows and already constrains ProviderCode — and not discipline in a prompt. Support traffic additionally gets its own EU-resident deployment, because the selected endpoint's data zone is verified; the owned registry keys clients by endpoint/credential configuration, not provider name alone.

0.4 Lifecycle

P draft → testing → published → retired, over the estate's existing prompt governance (Agent Framework). A profile publishes only when its eval set passes and the publisher holds the prompt-publisher role. Published versions are immutable; a change is a new version, and rollback publishes a new version containing the previously accepted content. Session records name the profile version that ran, so a case is reproducible after the profile has moved on.

0.5 A worked profile — the example

P One row, as the layering rule allows (D145). Each module's full profile table — what a profile owns, its hardest judgement, what it boots from and writes, its tools per environment scope, what it is denied, where it escalates and the eval set that proves it — is that module's Components § 3: Configuration · Support · Development.

0.6 Auto-learning a missing domain

P A domain node is never a prerequisite for work (decision 01.09.2026). When an agent needs a domain that does not exist yet — most often source/serdica-backend/<microservice> — the platform launches a summarizer sub-agent that reads the subject (the service's code, its AGENTS.md, its build and test surface, its recent history) and drafts the missing material for the owning profile before work continues.

• The summarizer writes a case-local proposal for the node it was launched for, under the Agents Memory § 2 writing practice.
• An existing but stale node receives a proposed new revision — the belief order applies: running system → consuming code → memory.
• Its output is an audited proposal, visible in the case chat; only the owner activates it.
• The node-creation gate (Agents Memory § 2) still applies to manual node creation; this is the automatic path, and its justification is that an agent actually needed it.

C How deep a summarizer goes on first creation, and what triggers a refresh of a node that already exists — a staleness signal, a schedule, or the next case that finds it wrong.

1. Platform profiles (used by every module)

P Shared agents and their complete input/output, method and runtime-access definitions are in the common catalogue. The intake mechanism is defined separately. These are references; profile implementation detail is not duplicated here.

P For the runtime they are declared the way module profiles are: platform-profiles.json carries key, execution kind, role and owned memory node for platform.intake, platform.compactor, platform.summarizer and platform.grader, with the eval set each model profile must pass before it publishes (§ 0.1). validate_runtime_contracts.py checks it against the module manifests and the catalogue, so no runtime profile — in a trace, a task or a ledger row — exists without a declaration.

2. Configuration module

P Described where it is built: Components — Configuration § 3 carries every profile of this module in one table — what it owns, its hardest judgement, what it boots from and writes, its tools per environment scope, what it is denied, where it escalates, and the eval set that proves it. The tree is drawn at the head of Configuration Module § 0.

3. Support Root and Data & Manipulation

P Described where it is built: Data & Manipulation components § 3 carries every support.* profile in one table — what it owns, its hardest judgement, what it boots from and writes, its tools per environment scope, what it is denied, where it escalates, and the eval set that proves it. The desk's tree (root, triage, the route, the communicator) is drawn at the head of Support Root § 0; the working stages' tree (investigators, validator, resolution, curator) at the head of Data & Manipulation Module § 0. The two share support.root (D144).

4. Customer-specific development module (id source)

P Described where it is built: Components — Development § 3 carries every profile of this module in one table — what it owns, its hardest judgement, what it boots from and writes, its tools per environment scope, what it is denied, where it escalates, and the eval set that proves it. The tree is drawn at the head of Customer-Specific Development Module § 0.

5. How the modules reach each other

P There are exactly two ways — and conflating them is the mistake that turns a graph into a mesh nobody can reason about.

P The consult rule (decision Vladimir, 03.09.2026 — D92). A consult is addressed to a knowledge domain, never to a case and never to a person:

1. The asking agent names the domain and the question. It may not name an agent, because which profile owns a domain is that module's business.
2. The platform spawns that domain's owning profile as an isolated, read-only sub-agent of the asking case, booted from the domain's AGENTS.md node and given the asking case's grants narrowed to reads. No case is opened in the other module, no queue is joined, no gate fires — which is why a consult is cheap and a handover is not.
3. The answer returns as a paper in the asking case, carrying the domain, the question, the answer and its evidence, so a decision made on a consult is auditable months later.
4. A consult that turns out to need a write is not a consult. The consulted profile cannot write — it has no write connector — so it answers "this needs a change in my module", and the asking root raises Hd. The rule is enforced by provisioning, not by instruction.
5. Depth one. A consulted profile may not consult onward. If it needs a third domain to answer, it says so and returns; the asking agent decides whether to ask that domain itself. This is what stops a question from touring the estate.
6. The trigger is the existing two-failed-attempts rule: an agent that has twice failed to establish an unknown contract or state consults the owning domain instead of trying a third time.

P The consult catalogue — who answers what. It is configuration (consults.catalogue, Whitelabel Catalogue § 5b), not a rule of the architecture, because a second customer's estate has different domains. The platform row below is the example (D145); the module rows are catalogued where the work is, in each module's what it asks of the others section — Support Root § 3, Configuration Module § 4b, Customer-Specific Development Module § 2b.

P The four handover directions, each a sub-case inside the same case, each behind Hd:

The worked example (D145): a print template's gate row is wrong and the fix is configuration, not code — Support → Configuration. The examples for the other three directions are on the module pages (Support Root § 3, Configuration Module § 4b, Customer-Specific Development Module § 2b).

P Handover protocol (D66): the receiving root accepts — its sub-case opens inside the same case, with its own stages and gates — or rejects with a reason (out of scope, missing information, wrong module) that returns to the requesting root as a DeadEnd-carrying message; the requester re-plans or raises H6. It never hangs. The requesting case parks on the sub-case like on a question (Agent Runtime § 11.4): its SLA clock follows its own class, the parked state and the sub-case's age are first-class fields on the Sessions screen, and a sub-case exceeding the requesting case's gate-escalation interval escalates to the requesting case's human the way a parked gate does (PG-12). Completion returns the result artefact to the requesting case, which owns the customer-facing closure — the customer hears one voice, not three.

P The handover packet is one paper in three parts, the same for all four directions (D142, 04.09.2026 — draft contract handover-packet.schema.json, Contracts § 2): the request — what is asked, why the requester cannot do it (the mechanism or placement finding), the kind (configure · build_or_fix · process · plugin · ddl), what the sub-case inherits (paper references, the grants narrowed to reads, the same handle map so no identifier is re-exposed), what done means for the requester, and the dependency on other sub-cases (G-12); the response — accepted with the sub-case id and its predicted minutes, or rejected with one of the three reasons; the completion — result, proof level reached, what changed with the WRITE_LOG ids and the standing revert path, and the done-means list ticked item by item. A module may extend the body per case (D139) — the receiving root reads the core and never the requester's transcript.

P source.root → the estate's development process is neither of the two: it is an exit. A core-change proposition leaves the platform for the estate development lead as a GitLab issue on master; the Development task returns the issue as an external-owner result; the owning case retains its delivery obligation and receives its state changes as ledger events (D108; Stage Planning § PL-1).

5b. What a root knows, and what it deliberately does not

P A module root is the only profile that reaches a human and the only one that may open a sub-case in another module. That makes what it boots from a design decision, not a convenience:

P A root does not boot from its stage domains, and that is deliberate: a root that knows the catalogue's dependency order starts making catalogue decisions, and the stage agent it delegates to becomes decoration. The root owns whether and who; a stage owns how. P For the same reason a root holds no direct estate-write connector or estate-execution skill. Its coordination, applicability and consult skills support plans, gates and messages; deterministic services still enforce authority.

5c. Who routes an arrival, before any module owns it

P Intake is a deterministic entry protocol with model-assisted briefing only after a case's authority and data boundary exist. Channel readers normalise metadata, stamp the source request/revision key, resolve explicit mirrors, resolve customer and verified sender, and store ARRIVALS. Sender role hints in a message are untrusted; roles come from authenticated identity or the configured channel identity mapping.

P A client arrival first checks the right to open a Support intake case. Granted intake opens the case automatically with the configured read-only case type, allocates its handles/papers and schedules support.root/S1. It does not wait for an Inbox click. Missing identity or denied intake stays a refused/awaiting-authorisation arrival; no investigation runs. An explicit operator start checks the named module's initiation rule before opening its root.

P S1 owns classification, severity, precedent retrieval and clock calculation. Intake supplies channel hints, never a conclusion about the working module. Before the route starts Configuration or Development work, the service checks the destination entitlement against the classified work and the verified initiator. This removes the circular dependency of deciding a destination before classification. An Operator's recorded handover authority can sponsor that work; the customer's message alone cannot.

P Customer representatives may start Support by default and request Configuration; an organisation enables direct Configuration initiation by its existing intake.initiation policy. That is a setup entitlement, not a repeated vendor request per tool call. The four client screens show which outcome applies. Development placement/core-change boundaries remain unchanged.

P Deduplication uses source identity and explicit mirror links. Similar subjects or object handles create a duplicate candidate, not proof that two requests are identical. Source updates add immutable material revisions to the existing case; they do not overwrite an approved paper or silently reopen a closed case. The root invalidates affected plan/gate revisions when material changes.

P Scheduled channel scans run as administrative, read-only maintenance tasks under configured customer/channel grants; they are excluded from business-case throughput metrics. Source bytes remain at the channel or in a restricted intake staging store until the destination case can own its papers and handle map. This avoids creating a PAPERS/CASE_HANDLES row before its required CASES parent.

6. Budgets and caps per role P

The budget is time (D135): the case's predicted delivery minutes, shared out by the root. The other columns are caps — fixed protections that do not draw down the budget.

Numbers are starting values for the T1 experiment, revised from the ledger. Provider usage per task is recorded in COST_LEDGER (tokens, calls) beside the minutes charged, so the spend envelope of Metrics remains a control without becoming a second budget dimension.

Challenges

• P Which investigator leads a cross-system symptom — set on the first ten Support cases (Stage Investigation § 2); until then the root picks by the customer's phrase and records the choice.
• P Consult mechanics P (Challenge Rounds § R2 § 2). A consult is a TASKS row kind = consult with deadline and priority; the per-domain queue is a view over open consults, taken by any pooled worker. Every consultable profile reserves budget.consult_concurrency (default 2 — a configuration value) that stage work cannot consume. A consult spawns an isolated read-only sub-agent inside the asking case (§ 5, D92) and never writes; it reads only under the requester's grant subset. Deadlines: 10 min for a memory-only consult, 30 min when reads are needed, never past the requester's remaining budget. On expiry the runtime writes ConsultReply {no_answer, reason, waited_s, queue_depth} with trust class absent; the validator treats it as unsettled; the same question hash in one case returns the earlier reply. Priority = the requesting case's SLA class, FIFO within it, one step up at ≥ 80 % budget or a waiting gate; no preemption. Unanswered consults emit a Finding to the owning domain — the dreaming pass reads them as missing articles. Confirmed when: T1 targets: no_answer < 5 %, p95 wait < half the deadline.
• P Profile inheritance — decided (Vladimir, 02.09.2026 — D50): whole profiles, no runtime inheritance; a module default is an authoring template only. The example. The five Configuration stage profiles share most fields: budget thresholds 80 % / 100 %, escalation to configuration.root after two failed attempts, route class "any" (no personal data), memory read = the whole tree, denied context none, eval-set policy. They differ in four: the prompt version, the memory write node, the tool set (S2 oracle-anlt + gateway, S3 oracle-iprod + browser …) and the stage skill. Runtime inheritance would declare configuration.abacus.builder extends configuration.stage.default and let the runtime resolve the chain at each turn — so a change to the default silently changes every published stage, which is what versioning exists to prevent. Whole profiles with an authoring template (the proposal): configuration.stage.default exists only as a template; "new profile from template" copies its values into a self-contained draft row; the ledger's profile version is complete on its own; a default change changes nothing published; revisit past 40 published profiles or when one change must touch more than 10.