Public use case

AMS Ticket Agent

An AI-assisted ticket workflow can summarize incidents, find missing information, propose routing, and prepare proposed responses. It must not close tickets, approve exceptions, change production state, or export restricted data by model judgment alone.

Models propose. Deterministic systems validate, approve, execute, and audit.

Problem

AMS work is context-heavy and authority-sensitive.

Support teams need faster triage and better use of historical knowledge, but operational tickets often contain customer data, entitlement context, production history, runbooks, and action paths that carry real business risk.

Useful assistance

Summarize history, identify missing fields, suggest category and assignment group, retrieve approved knowledge, and prepare a proposed response.

Risk boundary

The model must not own priority changes, ticket closure, customer commitments, exception approval, or production changes.

Control goal

Turn AI output into a proposal that passes through context, egress, runtime, approval, and audit controls before action.

Stack mapping

Each project owns a different part of the workflow.

The use case is deliberately split so context governance, data movement, runtime placement, and product workflow are not collapsed into one control layer.

ContextOps Governed context supply
Owns ticket history, approved knowledge, entitlement context, context owner, source provenance, freshness timestamp, and renewal rules for runbooks or playbooks.
ContextBoundary Visibility, callability, approval, denial, egress, and audit
Governs which fields and tools are visible, which capabilities are callable, which actions need approval, which actions are denied, and which data is constrained before it leaves the boundary.
Sthala Governed runtime placement
Places the AI runtime under approved boundaries for the ticket context involved. It implements placement; it does not redefine the egress policy.
Griha Product and workflow proof
Can demonstrate the user-facing flow: ticket summary, missing-information checklist, suggested assignment, proposed response, approval step, and audit trail.

Action policy

The model proposes. The workflow decides.

A ticket agent is safe only when the workflow distinguishes low-risk assistance from actions that require deterministic validation or human approval.

Allowed model work

Summarize ticket and interaction history
List missing information
Propose category and assignment group
Retrieve approved knowledge articles
Prepare an operator-reviewed response

Not model authority

Close a ticket without workflow approval
Change priority without policy validation
Send a customer-visible response directly
Approve an exception
Export restricted ticket data

Evidence

What a sealed receipt looks like Example

The section above says the model proposes and the workflow decides. This is that, on one run of the reference gateway — the record it produced, and how to check it yourself.

What the agent asked for

Invoke apply-change as agent:run-l1

deterministic check

What the gateway decided

approve rule R3 · tier_escalation

Held, not executed. Requires role:run-lead-apac to approve before anything runs.

Sealed, and checkable by a stranger

policy 8ec5c23a…502c7188

event 66a14a25…afc4c5a8

hash_alg sha-256

Produced locally from the reference gateway's AMS example — ephemeral test keys, example policy. Alter the agent signature, any payload field, the hash chain or the gateway seal and each fails with a different named code. Verify it yourself, from a clean clone of the reference gateway:

node audit/verify-receipt.mjs examples/ams-ticket-change/receipts/sample-receipt.json --public-keys examples/ams-ticket-change/receipts/sample-public-keys.jsonIt prints valid: true, code: intact, event_count: 3.

Controls

Controls before production authority.

The agent can increase speed without becoming the authority holder. The control path turns generated text into a governed proposal.

1. Curated context package ContextOps supplies owned, fresh, traceable ticket and knowledge context.

2. Boundary check ContextBoundary limits visible fields, callable tools, egress, and action categories.

3. Proposal generation The model summarizes, extracts, classifies, and proposes the next step.

4. Deterministic validation Workflow rules, schema checks, dry-run checks, and policy gates validate the proposal.

5. Approval and audit Human or policy approval owns the final action, and the system records source context, proposal, approver, destination, and final state.

Review questions

Questions before implementation.

These questions help teams decide whether an AMS ticket agent is ready for controlled delivery.

Context readiness

Who owns each knowledge source?
How is freshness recorded?
What happens when a runbook expires?
Which sources are advisory rather than authoritative?

Boundary readiness

Which ticket fields are visible?
Which tools are callable?
Which actions require approval?
Which destinations are denied for restricted data?

Runtime readiness

Where does ticket data run?
Which runtime is approved for regulated or customer-sensitive context?
How are prompts, retrieved context, and outputs logged?

Audit readiness

Can the recommendation be replayed?
Is the approving actor recorded?
Can rejected proposals be inspected?
Can downstream rework be measured?

Standards alignment

Map the use case to existing governance language.

Context Stack does not replace enterprise frameworks. For AMS, it should sit alongside service management, architecture, security, and audit practices already in use.

ITIL / ITSM

Incident management, knowledge management, change enablement, approval paths, and operational handover.

ISO/IEC 20000

Service-management controls, role clarity, service reporting, and continual improvement evidence.

Security and audit

IAM alignment, data minimization, logging, access review, egress constraints, and exception handling.

Source references

Use these sources to move from the example into the framework.