The Ask at a person's agent — from the words to the receipt, step by step

2026-09-29. One conversational ask at `demo-a2a`, followed through the code in the order it runs: how the caller is admitted, how the agent's playbook is loaded, how the request is grounded and judged, how a skill is selected and a plan is made around it, how the plan is admitted, how every step is gated by authority, executed, reconciled and receipted, and what comes back. Then nine real asks walked in full. Companion to the HeartCoach note (the HeartCoach Ask walkthrough), which describes the app-side harness that does NOT run here.

Code (paths under ~/agenticprimitives): apps/demo-a2a/src/index.ts (the doors), harness-run.ts (the harness as this Worker binds it), skill-apply.ts (instruction skills), standard-a2a.ts (A2A 1.0), run-export.ts / run-records.ts (provenance); packages/orchestration/src/loop.ts (the run loop), selection.ts, judgment.ts, intent.ts, outcome.ts (judging and selection), admission.ts, conformance.ts (plan admission), authority.ts, input.ts (the ports); packages/harness/src/playbook.ts, mandate-verifier.ts, policy.ts; packages/tool-policy/src/step-risk.ts. Specs: 350 (the authority-aware harness), 354 (archetypes and the compiled definition), 397 (ask-as-me), 410 §2 §5 (receipts and version binding), 415 (instruction skills, the assessment program), 416 (skill selection by judgment), 418 (the domain's tests and per-step operations), 379 (outside agents as steps), 385 (confirmation memory).

1. What an ask is here

An ask is one sentence from a person to an agent. The agent is a Smart Agent address (the addressee); the person is another (the asker); the two may be the same. The harness turns the sentence into a plan of steps, runs each step under the authority the person actually holds, and answers. Three doctrines govern everything below:

• "Intelligence may be probabilistic. Authority must not be." The planner proposes. The mandate authorizes. The executor acts. The receipt proves. (spec 350)
• "The ontology proposes; a judge decides; a declared rule accepts; authority is checked separately." Selecting a skill never permits anything; the chosen step still runs under every gate. (spec 416)
• "An archetype changes what an agent KNOWS HOW to do, never what it MAY do." The playbook is a digest-pinned document the custodian assigned; a moved digest is a bare harness. (spec 354)

There are four doors, and they all end in the same function:

Every door reaches runUnderMandate → runIntent (the loop) → askReplyFor (the reply).

2. From the screen to the harness

The Home's Ask screen sends one JSON body per turn:

{ "session": "<Home id_token>", "addressee": "0x…", "message": "Can you get david added to Missio Nexus?",
  "runRef": "…", "supplied": [ { "stepRef": "…", "signature": { … } } ], "surface": "home", "tz": "America/…" }

• `addressee` is who you are asking. `asker` is who the session says you are. They differ when a steward asks an organization's agent, or a member asks their team's. ownAgent (asker = addressee) is what unlocks the person's memory and preferences records for the run.
• `runRef` + `supplied` carry a suspended run forward: after the person signed a mandate, answered a prompt or confirmed a choice, the same ask resumes with what they did, and nothing else is re-sent. The agent holds the question, the plan and every earlier answer under the runRef (spec 350 W3).
• A screen may supply the plan for an informational read it draws itself ("who are my contacts" with plan: { steps: [{ toolId: 'person.contact.list' }] }) and gets results[] back beside the sentence, so the panel renders rows rather than parsing prose (spec 361).

What comes back is one of six reply kinds (section 3, step 12), always with a runRef and, when a plan was made, a plannerTrace that says which stage decided what.

3. The harness, step by step

The order below is the order in index.ts (the route), harness-run.ts (binding) and loop.ts (the loop).

Step 0 — Admit the caller

1. Normalise the addressee. 0x… or a CAIP-10 eip155:<chain>:0x…; anything else is 400.
2. Ask-as-me? If the request carries Authorization: A2A-Session …, verifyAppDelegation checks the wire's signature by ERC-1271 against the universal validator, that the delegation is not revoked on the DelegationManager, and that the caller assertion is spent exactly once at the addressee's task object. The run then proceeds as the person with no Home session: reads under their standing, every act parking for the mandate only they can sign.
3. Forwarded credential? On a routed hop the bound body's addressee must be the asker's own agent or the room that routed the step, the audience must be this deployment's zones, and the assertion is spent on the receiver's object.
4. Otherwise a Home session. verifyHomeSession verifies the broker's JWT (issuer, audience, JWKS) and the subject is the asker's address.
5. The door's own checks. HARNESS_AGENT_SA configured; the agent's budget record (429 when spent); an evaluation variant only under EVAL_CAPTURE=on and a caller who may oversee the agent; the model provider resolved (a provider not offered on this estate is 400).
6. Resume? A runRef loads the run: must be claimable by this caller (403), not a workflow's (409), not expired (410); a completed routed operation is replayed, never re-run.

Step 1 — Load the playbook

loadPlaybook(addressee) reads the agent's vault record archetype.assignment (ap.archetype-assignment.v1), written by the custodian or a steward and pinning an exact (archetypeVersion, definitionDigest). The harness recomputes the definition's digest and compares; a mismatch is the bare harness ("this agent has no playbook for that"). The validated PlaybookScope holds: archetypeId, archetypeVersion, digest, capabilityIds, instructions (the planner doctrine is the text above ## How each act is done), triggers, specialists, declaredEffects, tools (the definition's tool contracts by capability id), retrievalQueries, domainLexicon (every domain class with its label, terms, clusters and typical uses) and domainRecords (record type ↔ class). The digest is stamped on the intent as versions.semanticsDigest, beside the ontology manifest digest, so the mandate verifier later refuses a step whose T-box or definition has moved (spec 410 §5). Cached one minute.

Step 2 — Offer the tools

The tool list for this run is built from the playbook, never fixed:

A duplicate id throws. The playbook's contract utterances become the planner's few-shot examples.

Step 3 — Ground the request

Before any model call on the request:

1. Open intent. classifyOpenIntent(goal, OUTCOME_CLASSES) is a deterministic word match on the ontology's outcome classes: exactly one hit types the intent ({ class, bounds }) into intent.constraints.outcome so the mandate digest covers it; zero or two hits leave it closed.
2. A held mandate already presented adds "ALREADY granted authority to … do not choose another" to the planner's prompt.
3. Compiled shapes — regexes, no model — are tried in order: a skill answer, a consult, a read (balance, members, affiliations, records, receipts), a fan-out, a payment, a routine (own agent only). A hit is the plan (plannerUsed: compiled) and steps 4–5 are skipped.
4. The typed reading for the judge (inferIntent → renderReading): the domain terms the sentence names, their cluster neighbours, the asker's relation (self / steward / member / stranger), and under SKILL_SELECTION_ASKER_CONTEXT=full their recent skills over 30 days and memory tags, plus the role the tags ground to and the classes they already hold. "Evidence, never a filter: nothing here removes a skill."

Step 4 — Judge which skill (the selection stage)

Runs only when no compiled shape matched, the playbook has instruction skills, and the estate turns it on (SKILL_SELECTION_DEFAULT: faithnet selective; production unset, so the planner model decides there).

• One call, one question, to the light-tier model (Gemini flash-lite on faithnet), profile ap.skill-selection-judge.fast.v2: "Which ONE offered skill should handle this request?" over the skills' cards (one line of purpose, Produces: …, Not for: …, from the ontology's covers and excludes) plus n/a = "No offered skill fits: the request is out of scope, merely adjacent to a skill, or too small or personal for any of them." The state is the typed reading; the cards are a cacheable prefix. The answer is a probability distribution over the options, nothing else.
• The acceptance rule is code over the numbers: n/a on top → none-fits; top confidence < 0.5 → below-floor; lead over the runner-up < 0.15 → no-margin; otherwise the top skill is chosen. Under SKILL_SELECTION_SPLIT=clarify a split between two skills whose mass together ≥ 0.7 becomes "ask the person"; SKILL_SELECTION_BORDERLINE=on re-asks once inside [0.35, 0.6] and averages.
• Outcomes: a skill → step 5 plans around it; needs-clarification with two rejected skills plans ask.clarify with exactly those options; none-fits / a hold hands the request to the planner with the skills removed from its tool list (trace.skillStage = handed-to-planner), so a plain act or read is planned and a request nothing fits ends as ask.unsupported.
• Selection never permits anything. The receipt records the arm, the candidates, the distribution and the choice; the step still meets every gate below.

The thorough profile (v5), the ontology arms, the conformal acceptance and the measurements are in section 4.

Step 5 — Plan around the pick

• A skill was chosen. Under selective with SKILL_SELECTION_PLAN=choice (faithnet), choosePlanAround enumerates three plans from the outcome graph — the pick alone, a producer → the pick, the pick → a consumer — and one more judge call (ap.plan-choice-judge.v1) picks: "a two-step plan only if the request wants BOTH results (or needs the first to make the second)." The graph is the ontology's produces / consumes between skills; a class the request supplies or the asker already holds needs nothing; one another skill produces prepends that skill; anything else is missing and named ("ask for it rather than invent it"). Bounds: depth 3, four steps. Without consumes declared anywhere the plan is the single step { toolId: <skill>, args: { question: <the ask> } }.
• No skill was chosen. The planner model (gemini-3.5-flash-lite on faithnet, 1024 tokens) plans over the remaining tools with a system prompt of the playbook's doctrine, the fixed planner rules (fan-out, $when, $executor), the conversation, the memory and the contract utterances as examples. With no provider configured, a rule-based planner runs instead.
• A plan is { steps: [{ toolId, args, id?, ref?, forEach?, when?, executor? }], rationale? }; args may bind to earlier steps ($ref), fan out ($forEach, $item) or branch ($when). Specialists from the playbook are stamped as executors. With PLAN_REGRESSION_DEFAULT=on (faithnet) the plan is completed backwards from the goal through the capability transitions.

Step 6 — Admit the plan

planAdmission runs every rule and reports all violations at once. Deterministic, over declarations only: "never a second model, never a regex over English that guesses intent." In the order the harness lists them:

admitPlan then: all continue → append and re-admit; all ask → drop those args so they become prompts; any refuse → terminal denied; anything else → one re-plan told the violations, and a second failure is denied (plan_refused: …). A plan that acts is exempt from the question rule: "a plan that ACTS is not answering a question."

Step 7 — Resolve each step's arguments

Names become addresses in the asker's tier (resolveStepArgs); a name that resolves to nothing, or to several, throws InputRequired and the run suspends with a data prompt (or a choice prompt among the candidates). A choice the person confirmed before is remembered as evidence scoped to (word, capability, argument) and cited — "remembered: you chose X for this before" — but it authorizes nothing (spec 385). Supplied answers from a resume are merged here.

Step 8 — Authority, per step, never per run

For every non-informational step:

1. Routed? When the subject agent judges the step, this run records presentedRef: routed and relays.
2. Self-authorized? A tool the session itself authorizes records presentedRef: self.
3. Otherwise `authorize()`: pick a mandate from the keyring (by payee for a payment); with none, under onMissingMandate: report, the outcome is `authority-required` with the exact requirement (stepRef, toolId, capability, args, derivation); with one, the mandate verifier checks signature, revocation, the intent binding (plan digest, versions) and answers allow, approval-required or deny; obligations are the verifier's plus the risk ladder (high → second-party approval; critical → second-party approval + quorum + fresh authorization) — the capability and risk come from the tool's declaration, never from the plan; the approval port returns a signature prompt over the approval digest, refused, or discharged after ERC-1271; after a discharge the verifier runs again: "an approval is an input to the verifier, not a bypass of it."
4. The reply. askReplyFor turns authority-required into the authority_required kind: the requirement bound to the plan, the delegator (the capability's authority, else the resource, else the addressee), the delegate (this agent's HARNESS_AGENT_SA), the asker's standing to the delegator with canGrant, the parties the words became ("send nathan a message" is authorized against an address), and alsoApprove when one signature covers more (an invite's grant and credential digests). The run checkpoints with awaiting: authority; on A2A the task parks as TASK_STATE_AUTH_REQUIRED.
5. Grant and resume. The person signs at their Home (/you?run=<runRef>; Home MCP's grant_link returns that URL), then the same ask resumes with presented; the stored plan must match and everything is re-verified from scratch.

Step 9 — Reconcile, then execute

1. Reconcile before acting. The reconcile port asks whether this exact effect already happened (found: the earlier receipt is reused and no second act runs; absent: proceed; indeterminate: stop). A resumed run never pays twice.
2. Invoke. A hand-off to another executor derives a child mandate from the parent; discovery, engagement and routed subjects go to the subject agent and relay its progress; everything else is local: playbook.answer (a templated answer), skillApply for an instruction skill, harnessInvoker for the action tools, MCP for connectors.
3. An instruction skill at answer time (skillApplyInvoker): the SKILL.md body is read from SKILLS_MCP by the pinned digest and refused if the commitment moved; the model runs once under the apply system prompt + the body with the question and the material (1400 tokens; 600 when brief); SKILL_ANSWER_MODEL_DEFAULT=minimal and streaming on faithnet.
4. An outside agent answers over A2A with a 20-second timeout; its card digest is pinned; its words come back as an observation the composer must attribute.
5. Receipt, then declared effects through the effect sink, isolated so a failing side effect cannot fail the act. Consecutive independent reads run in parallel.

Step 10 — Answer

• ask.unsupported → a fixed "I can't help with …" sentence.
• Every step declares an answer template (instruction skills) → the answer is rendered, no composer call.
• Otherwise → the grounded composer, checked by checkGroundedComposition, one recompose, then a grounded fallback. An outside agent's words are attributed ("clock.external says…"); a read that wrote a query returns it as evidence ("I searched names for the word 'organizations' and matched none").

Step 11 — Receipts and provenance

Every step receipt carries skillRef { skillId: archetypeId, version, commitment: playbook.digest }, the step's own skill { id, version, contractDigest }, the binding (intent digest, principal, subject, resource, authority, expected outcome, operation id, arg sources, standing, actor), inputDigest, planArgsDigest, derivation, the observation (attempted | accepted | committed | confirmed; only an independent read-back may be called confirmed) and attests. The receipt sink writes harness.step.<status> audit events; large results are offloaded to run.artifact: records; the run record (door, model calls, variant, operational stages, bill) is kept about a week on the agent's task object; exportRun writes run.provenance:<runRef>, an anchor and measures into the agent's vault and answers a PROV-AQ Link header. The playbook manifest rides on the A2A artifact.

Step 12 — The reply

{ "ok": true, "addressee": "0x…", "runRef": "…", "hasProvenance": true, "resumable": false,
  "reply": { "kind": "answer" | "authority_required" | "prompt" | "waiting" | "done" | "refused", …, "spoken": "…", "plannerTrace": { … } } }

answer { text, results?, interaction?, next?, evidence? } · authority_required { requirement, delegator, delegate, capability, stepRef, summary, standing?, parties?, alsoApprove? } · prompt { resumeToken, prompt } (data, signature, confirmation, commitment, authority) · waiting { on, commitment, text } (another agent's steward) · done { result, receipts, fulfillment, effects, decisions } · refused { outcome, error, receipts }. plannerTrace names the planner used (compiled, judgment, a provider, rule-based, supplied, replay), the selection arm and its distribution, every admission verdict, the structured calls and tokens.

4. Judging in detail

The arms, as the orchestration package ships them

Acceptance is always a declared rule over numbers: floor 0.5 / margin 0.15 / fit ≥ 0.5, or, when a calibration map is cited (416 W3), temperature scaling then a conformal set: every outcome whose calibrated probability ≥ 1 − q̂; one skill in the set routes; several → ask the person among exactly those; none alone → decline; empty → decline. The map is fitted on labelled runs of this binding and cited by digest on every decision.

What the measurements said (spec 416, faithnet, 12 CIL skills)

What faithnet runs today

SKILL_SELECTION_DEFAULT=selective, SKILL_SELECTION_ASKER_CONTEXT=full, SKILL_SELECTION_PLAN=choice, PLAN_REGRESSION_DEFAULT=on, ORCHESTRATION_LLM=gemini,anthropic (Gemini first: flash composes and answers, flash-lite plans and judges; Anthropic claude-haiku-4-5 only when named), ORCHESTRATION_ROUTE=budget, ANSWER_STREAM_DEFAULT=on, SKILL_ANSWER_MODEL_DEFAULT=minimal. Production sets none of the selection variables: there the planner model decides. Evaluation cases are ontology individuals (apeval:expectedSkill, forbiddenSkill, expectedBehaviour route / decline / clarify / several, underStartingState), held-out sets are write-once, and a disputed gold label is adjudicated by a person against the skill's contract, never edited because a judge disagreed.

5. Nine asks, walked in full

The asks are the evaluation program's own cases (skills/evaluations/agentic-trust/home-acts-1.src.json, cil-commons/fresh-heldout-5.src.json, fresh-heldout-6.src.json, agenticprimitives/scripts/ask-scenarios.heldout.json) and the live example in spec 385. Alice asks her own agent at faithnet unless said otherwise.

5.1 "Who's in Missio Nexus right now?" — a read, no model

5.2 "Can you get david added to Missio Nexus?" — an act, and the mandate only she can sign

5.3 "Add dave to my contacts." — the adjacent act, kept apart

Same shape as 5.2 up to the plan. The typed reading names contact, not membership; the planner picks person.contact.invite, and the case's forbidden skill is organization.membership.invite. "Add" is the ambiguity spec 416 §2 names ("add Jane" may be invite or enroll); here the object word settles it before any judge, and the mandate she is asked to sign names the contact grant, not an organization.

5.4 "Send 2 USDC to nathan.treasury toward the retreat deposit." — a payment with a marked default payer

5.5 "Pay nathan.treasury back for the hymnals." — a number nobody said

The payment shape matches without an amount. Admission's numbersFromTheWords refuses a planned amount the person never said; the recovery is ask: the arg is dropped and the run suspends with a prompt of kind data for usdc | amount. Expected: prompt. Nothing is planned, nothing signed.

5.6 "Is our intake screening model okay to keep using?" — two skills could, so ask

At a CIL-commons organization's agent, whose playbook carries twelve instruction skills.

5.7 "Write the Marlow Foundation inquiry letter, and once it is done put it on our funding tracker." — several

5.8 "Should we order pizza or sandwiches for Saturday's volunteer training?" — nothing fits

The fast judge answers n/a ("too small or personal for any of them") → none-fits. The planner is handed the request with the skills removed and finds no read or act for it → ask.unsupported → the fixed "I can't help with …" sentence. Expected: decline. Gold null; the control the asker-context runs kept.

5.9 "invite carol to thompson" after "invite bob to thompson" — a remembered choice, still gated

The first ask asked which thompson (two candidates in Alice's tier) and Alice chose. The second resolves "thompson" from scoped confirmation memory (word, capability, argument) and cites it — "remembered: you chose X for this before" — then still reaches authority_required, because a remembered choice "authorizes nothing." (spec 385, live example)

An ask-as-me variant

HeartCoach's "My agent" door sends Alice's question with Authorization: A2A-Session <wire>: step 0 verifies the ask-as-me wire (pinned to harness.ask, time-bounded, revocable) and spends the assertion once; there is no Home session; the run proceeds as Alice under her standing and playbook; any act parks at authority_required with a Home link she must open herself. The host that asked is never a signer.

6. Timing

7. Where each piece lives

8. And HeartCoach

coach-a2a runs none of this. It fixes the archetypes by face and role, offers the model every bound tool with tool_choice: any, gates each act with its own admitToolCall and entitled, and reads under the patient's session rather than a mandate to the coach service. There is no judge, no plan admission, no mandate verifier, no receipt at the person's Home. The "My agent" door is the only place a HeartCoach ask enters the harness described here, and it enters as an ask-as-me. What it would take to run the coach consultation through this harness is in the HeartCoach note's discussion of the two-party shape.