When the Agent Needs a Human
Every autonomous system eventually meets a customer who needs something the system cannot provide: a refund decision, a custom integration, a “please explain what happened.” Support is the part of the service model that no amount of automation removes — it is what happens when the customer’s need crosses from the machine’s competence into human judgment. The S6 series has built the business on verifiable autonomy; this article is about the boundary where autonomy stops and the human support layer begins, and why that boundary is a design decision, not an accident.
Support as a product, not a cost center
The default view of support is a cost: tickets to triage, hours to staff, customers to soothe. The sovereign view is different: support is the highest-trust surface the business has. A customer who contacts support is already engaged enough to care, and every interaction is a chance to demonstrate the architecture’s honesty. The fleet’s support model therefore treats each ticket as a deliverable, with the same four-part contract as the service catalog (S6.4): inputs, outputs, constraints, evidence.
The evidence part is the differentiator. When a customer asks “why did this happen?”, the fleet does not answer from memory. It answers from the ledger: the audit slice (S7.15) shows exactly what ran, when, with which keys, at what cost. Support is the place where the verification story becomes customer-facing.
The escalation ladder: machine first, human when needed
The fleet’s support triage mirrors the Council’s escalation ladder (S7.10). The first line is the system itself: the customer dashboard (S6.7) answers routine questions — status, budget, history — without a human. The second line is an agent with a support skill: it can investigate the ledger, check tenant state, and draft responses, all scoped and audited. The third line is a human, reached only when the machine cannot resolve the issue.
Three design rules keep the ladder honest:
- The machine escalates with evidence. When the system hands a ticket to a human, it attaches the audit trail: what the customer asked, what the machine found, where the gap is. The human is not starting from zero.
- The human never impersonates the machine. If a human resolves a ticket, the customer knows a human resolved it. The response carries the human’s identity and the resolution’s evidence. Blurring the line destroys the trust the whole architecture is built on.
- Every resolution is recorded. The ticket, the investigation, the resolution, and the evidence are appended to the ledger. The fleet learns from every interaction, and the knowledge feeds back into the catalog and the runbooks.
Support tickets as research data
A support queue is a research dataset wearing a customer-service costume. Every ticket is a signal about where the product is confusing, where the documentation is thin, and where the automation is failing. The fleet mines the queue the same way the S10 series mines markets: patterns become backlog items, backlog items become improvements, improvements become catalog entries. A ticket that recurs is not just a support problem; it is a product problem with a measurable cost.
The feedback loop is explicit: the support resolution updates the knowledge base, the knowledge base feeds the content pipeline (S3.7), and the content pipeline produces the documentation and articles that prevent the next ticket. Support closes the loop that the S10.10 feedback flywheel describes — market signal becomes research becomes content becomes product.
The human cost is real and priced
Humans are the most expensive resource in a sovereign fleet, and the pricing model must reflect it. The tiered architecture (S6.8) handles this: lower tiers get machine-first support with human escalation on a schedule; higher tiers get faster human access and a dedicated escalation path. The price difference buys response time, not competence — the ledger is equally honest at every tier. Support pricing is transparent in the catalog, so the customer knows what they are buying.
The fleet also prices the human’s time internally. Every human-resolved ticket costs real minutes, and the cost is recorded. A support model that does not know its cost cannot improve — it can only guess. The ledger knows, and the catalog prices accordingly.
When support becomes the product
The most mature form of support is the moment it stops being reactive and becomes proactive: the fleet notices a pattern in a customer’s usage before the customer does, and reaches out with the evidence. “Your budget trend suggests you will hit your cap on Thursday; here is what happened last time and here are your options.” This is support as a service — the same machinery that runs the fleet’s own anomaly detection (S7.17) pointed outward at the customer’s tenant.
For a sovereign-infrastructure business, this is the strongest possible demonstration of the model. The customer experiences the fleet’s autonomy not as a black box that occasionally fails, but as a system that watches over their tenant with the same rigor it applies to its own. Support stops being a cost center and becomes the product’s living proof.
Grounded in wiki concepts customer-support, service-plans, subscription-model, immutable-logging, feedback-flywheel, and the S6 + S7 + S10 series. Design notes on a running system.
