Agentic Service Blueprinting: The Sixth Lane & Autonomous Workflows

The Sixth Lane: Agent Decisions

I do not add a sixth lane because agents are exciting. I add it because they make a specific class of work visible: interpretation, recommendation, tool selection, escalation, and refusal. None of that fits cleanly inside Support Processes. A database does not decide whether it has enough confidence to continue. A notification router does not weigh ambiguity and ask for help. An agent does.

The five canonical lanes remain intact: Physical Evidence, Customer Actions, Frontstage Interactions, Backstage Operations, and Support Processes. The Agent Decision Lane extends that structure for AI-native blueprints. It does not replace the old grammar. It sits alongside it so I can show where probabilistic reasoning touches deterministic infrastructure and human judgment.

That distinction is crucial because many service teams still describe AI as if it were a smarter rules engine. It is not. Rules engines execute declared logic. Agents interpret, choose, and sometimes drift. If I hide that inside Support Processes, I erase the exact moments where the service can go wrong in new ways: overconfident automation, silent fallback, escalation with missing context, looping between tools, or a confident answer unsupported by evidence.

The sixth lane also lets me distinguish between a system action and an agent decision in the same column. A scheduler database can return capacity. An agent can decide whether the returned capacity is sufficient to auto-confirm a slot or whether a human should review the proposal. Those are different kinds of moves. They deserve different marks, different review logic, and often different safety boundaries.

I keep the lane definition concrete. For every agentic node I want five things named: trigger, evidence basis, permitted action, escalation path, and boundary condition. Trigger says what wakes the agent. Evidence basis says what rows, artifacts, or signals it is allowed to consider. Permitted action says whether it may recommend, write, dispatch, or only classify. Escalation path names the human or downstream role. Boundary condition names the stop rule.

{
  "lane": "Agent Decision Lane",
  "nodeId": "care-routing-eval",
  "trigger": "new urgent request plus current capacity snapshot",
  "evidenceBasis": ["journey-map:urgent-request-v1", "telemetry:wait-stats-aug"],
  "mode": "recommend-only",
  "permittedActions": ["classify_acuity", "propose_route"],
  "escalationTarget": "clinical-ops-lead",
  "boundary": "stop on missing evidence or safety-stop rule"
}

Notice what the node does not claim. It does not claim that the agent is the service owner. It does not claim the host can magically spawn another agent. It does not confuse a logged decision record with live transport. That restraint is important across ASD. The platform is very explicit that ACP is `asd-acp/1`, record-only, and fail-closed on the generic surface. A lane can describe a decision. It cannot fabricate a capability.

Autonomy Patterns and Gate Semantics

The biggest mistake I see in AI service work is binary thinking. Teams talk as if a step is either automated or manual. Real services need a richer autonomy spectrum. Some actions are safe to automate. Some are safe only to recommend. Some are reversible but still sensitive. Some should stop outright and demand human review. The lane is useful only if it carries that nuance.

I use four autonomy patterns repeatedly. Classify-and-recommend means the agent proposes a route or summary but does not act. Auto-execute low-risk means the agent can perform a bounded action with a clear rollback path. Human-gated execution means the agent prepares the action, packages the context, and waits for approval. Safety stop means the agent halts because the case crossed a risk boundary, violated a policy rule, or lacked enough evidence to proceed honestly.

These patterns are useless without gate semantics. A gate is not a vibe check. It is a named boundary. For service design artifacts the review gate is often the Critic. For service operations the gate might be a clinician, a privacy officer, a journey owner, or a supervisor. What matters is that the lane shows who can authorize the transition and what record the authorization attaches to.

In Halo Care, the design principle was brutally clear: clinical safety was non-negotiable. Success criteria included virtual wait under eight minutes, DNA under ten percent, first-visit resolution above seventy-five percent, and no safety-event trend increase. That last criterion changes everything. It means speed and convenience can never silently outrank safety. So the agentic blueprint cannot merely optimize throughput. It must encode where the service stops, who reviews, and which Critic rows and gate minutes persist the decision.

In Sable & Slate the safety question was different but just as real. The brand promise depended on memory and recognition without crossing into dossier behavior. The non-negotiables were explicit: no visible tracking, no "algorithmic" service language, and human final authority. That means a memory-related agent can summarize consented facts and boundaries, but it cannot infer traits or stage a guest-visible performance without human judgment. Same lane. Different gate logic.

version: 1
policies:
  - id: low-risk-status
    mode: auto-execute
    allowed_actions:
      - prepare_status_message
      - attach_traceability_rows
    requires_human_approval: false
  - id: staffing-or-clinical-route
    mode: human-gated
    allowed_actions:
      - propose_route
      - assemble_context
    requires_human_approval: true
  - id: consent-or-safety-breach
    mode: safety-stop
    allowed_actions: []
    requires_human_approval: true
    stop_reasons:
      - missing_consent
      - unsupported_evidence
      - red_flag_condition

The nice thing about this policy style is that it keeps the conversation operational. We are no longer talking about whether the AI is "smart enough." We are talking about which actions are safe to permit, which records must exist first, and how refusal behaves. That is design language I can defend.

Typed Agent Handoffs as Durable Records

Once a service includes several roles or several agents, handoff quality becomes a first-class design problem. Chat is not enough. Memory of a conversation is not enough. A screenshot of a thread is definitely not enough. ASD's answer is durable, typed handoffs. They are records of condition plus artifact pointer, and the pointer must resolve inside the same project if one is declared.

The ACP contract is specific here. Event types include `handoff`, `orchestration`, `dispatch`, `critic-veto`, and `human-gate`. The generic CLI and MCP surface expose exactly one ACP capability: `{"protocolVersion":"asd-acp/1","capabilities":["record-only"]}`. Record-only means the platform can validate and persist a handoff record. It cannot pretend that a host process appeared, that another agent definitely replied, or that some external transport succeeded. This boundary is one of the healthiest things about the platform.

For blueprints, typed handoffs matter because the sixth lane often bridges human and agent work. A mapper hands a reviewed blueprint to an ideator. A triage agent hands a proposed route to a clinician. A concierge context service hands a guest brief to the front-desk ambassador. A care-routing agent hands a warm-handoff card to a clinician. In all these cases the receiving role needs the condition and the artifact, not vague recollection.

{
  "projectId": "halo-care-8fbf1a5a",
  "planId": "plan-care-routing",
  "from": "mapper",
  "to": "prototyper",
  "condition": "Warm handoff blueprint has passed Critic review and is cleared for storyboard walkthrough.",
  "artifactId": "68897cff12ba43a581451187b4918bf2",
  "artifactKind": "service-blueprint"
}

This record has consequences. If the `artifactId` is missing while `artifactKind` is supplied, the handoff fails before recording. If the artifact exists but is the wrong kind, it fails. If the pointer is dangling, it fails. That is precisely what I want. An agentic workflow should fail early on referential sloppiness. Otherwise the system ends up pretending it handed off a real thing when it only handed off a sentence.

The same logic shows up in the service-blueprinting flagship skill itself. Its declared handoff says that after the Critic review passes, the `service-blueprint` goes to the ideator with evidence and provenance intact. The wording matters. Handoffs are about continuity of truth, more than task delegation. The receiver should inherit the exact artifact that survived review, including the provenance basis that made it trustworthy.

In operational services, typed handoffs improve human experience too. Halo Care's warm handoff pattern is a good example. The design fix was a sixty-second handoff protocol: patient plus context card in thirty seconds, open clinical question in twenty, confirmation and next contact in ten. Rule: no new assessment in the handoff; red flag means urgent class. That compactness is only safe because the handoff payload is explicit and bounded. A naked escalation where the next clinician must restart the story is a service failure and usually a safety failure too.

Failure Modes: Drift, Loops, Silent Fallbacks

The sixth lane earns its keep when I use it to model failure honestly. Three patterns show up repeatedly. The first is drift: the agent's internal framing diverges from the actual evidence or policy basis. The second is looping: the service keeps re-querying, re-escalating, or re-summarizing without resolving the condition. The third is silent fallback: the service quietly degrades in a way the customer or downstream worker cannot interpret.

Drift often begins with over-broad summary. An agent compresses a guest history into a trait judgment, or a care request into a false urgency class, or a staffing problem into a generic capacity note. Once the summary drifts, every downstream step looks plausible and wrong. This is why Sable & Slate's no-trait-inference veto matters so much. The represented concept brief inserted "guest seems anxious" into the solution field. The Critic vetoed it. Correctly. Memory stores facts, requests, and boundaries only; never trait judgments. That is a design rule and a dignity rule at the same time.

Looping usually appears where ownership is unclear. An agent proposes a route, a human rejects it without a typed fix, the same route gets proposed again, and the customer experiences delay disguised as diligence. Or two agents keep handing a case back and forth because the condition for completion was never formalized. Typed handoffs help here, but only if the conditions are specific enough to break the loop.

Silent fallback is the most dangerous pattern because it looks smooth. A service quietly shifts from intelligent assistance to generic script, or from evidence-backed route to queue default, without preserving the customer's context or explaining the change. In hospitality that feels cold. In healthcare it can become unsafe. In public services it creates expensive chase demand. The antidote is visible degradation design: if the service falls back, the next actor gets the context and the customer gets a coherent explanation.

- drift: does any summary introduce traits, diagnoses, or motives not present in evidence?
- loop: can two roles hand the same unresolved condition back and forth indefinitely?
- silent fallback: if automation stops, does the next actor inherit usable context and a clear boundary?
- unsupported dispatch: are we assuming a host capability ACP does not claim?
- fake finality: did an artifact skip Critic review or a human gate?

ASD's record-keeping helps because it preserves the review and veto trail. A `review-veto-log` is not glamorous, but it is the living memory of what the service was not allowed to claim. In agentic systems that negative memory is invaluable. It reminds the team which optimizations crossed consent, safety, or measurability boundaries.

Case: Sable & Slate and Halo Care

Sable & Slate and Halo Care make a useful pair because they sit at opposite ends of tone and risk. One is luxury hospitality, where memory and recognition create value but must never become surveillance theater. The other is telehealth and virtual ward care, where any redesign has to move with clinical safety still in charge. Both cases needed the sixth lane because both involved agentic help under hard human boundaries.

Sable & Slate had nine properties, €680 ADR, and a brand promise built around remembered stays. A three-year digital programme had accidentally stripped out the memory by removing human continuity. Guests repeated preferences. Staff lost context across shifts. Turnover at thirty-four percent drained tacit expertise. The tempting move was obvious: build a guest emotion score and a magical memory engine. The platform refused the worst version of that fantasy.

The first major veto came in concept review. A context-memory concept included trait inference in the solution field. The Critic blocked it under `no-trait-inference`. The fix was sharp: memory stores facts, requests, and boundaries only; never trait judgments. That one move defined the design ethic for the whole service. The future-state blueprint then positioned the agentic work where it belonged: a backstage, consent-bound brief assembly step plus a visible human performance step in frontstage. The system cues. The staff perform. Human final authority remains intact.

A second Sable & Slate lesson came from shift handoff. The operational analysis found that a sixty-second brief degraded to three minutes under short staffing. The fix became a two-tier handoff: minimum brief and complete brief. That is classic sixth-lane work. The agentic layer can assemble the brief. It cannot decide that no handoff is needed. The boundary is the service design.

Halo Care had a harsher operating context. It needed to improve access without increasing safety-event trends. The redesign work registered 1,983 evidence rows in the synthetic scenario and used Critic vetoes plus signed human gate minutes as the governance mechanism. One review blocked a route that would have quietly returned patients to the old five-day queue. Another set of safety rules bounded the warm handoff and the context service. The point was clear: no service move that improved flow was acceptable if it undermined clinical safety or consent.

The warm handoff pattern became the emblematic sixth-lane design. The patient should not retell the whole story at each transition. The context card should follow. But the handoff rule stays clinically humble: no new assessment in the handoff, and any red flag escalates to urgent class. That is a perfect example of bounded autonomy. The agentic part assembles and carries context. The clinical judgment stays with the clinician.

{
  "projectId": "halo-care-8fbf1a5a",
  "type": "human-gate",
  "condition": "Warm handoff route passed Critic review; clinical lead approves regional pilot.",
  "linkedReviewLogId": "2de447148c3b4f36b294524d813fef40",
  "approvalRole": "clinical-lead",
  "boundary": "No region rollout if safety-event trend increases or consent rules are weakened."
}

Both cases underline the same point. The sixth lane is not where I celebrate autonomy. It is where I discipline it. At Sable & Slate the discipline protects dignity, brand, and consent. At Halo Care it protects safety, continuity, and professional authority. In both, typed handoffs and Critic review make the service more legible to the people who must trust it.

That is why I keep the sixth lane close to the rest of the blueprint rather than treating it as a separate AI architecture diagram. The customer still sees a service. The frontline still carries the brand. The backstage still absorbs trade-offs. The support layer still constrains what is possible. Agent decisions belong in that same production reality. Once I draw them there, I can finally ask the right questions: what may the agent do, what must it never do, who can veto it, how is the handoff typed, and how does the service fail without pretending nothing went wrong.