Build a support workflow using synthetic tickets and a local sandbox API. The agent should retrieve help documentation, propose a ticket update, and wait for a person to approve it. Do not connect the exercise to real customer accounts.
Tools and state
Expose three narrow tools: search_docs(query), get_ticket(ticket_id), and propose_update(ticket_id, text). Keep execution of an approved update in application code behind an authenticated approval endpoint. A model claiming that approval occurred is not authorization.
Persist a proposal ID, ticket version, proposed text, status, and approver identity. Model the states as draft → awaiting_approval → approved → applied, with explicit rejected and failed states. If the ticket changes after approval, require a new review of the updated proposal.
Build sequence
- Implement a deterministic search-and-draft baseline before introducing an agent loop.
- Add validated tool schemas, a maximum of five agent steps, timeouts, and clear stop reasons.
- Keep context isolated per user and ticket. Treat retrieved documents and ticket descriptions as untrusted data.
- Add approval in the UI or API. Bind approval to the exact proposal and enforce authorization on the server.
- Make application of an approved action idempotent: retrying the same proposal ID must not duplicate the update.
- Capture a trace with tool names, status, timing, and safe summaries rather than secrets.
Acceptance checks
Use at least 20 synthetic cases covering useful answers, missing evidence, nonexistent tickets, timeouts, invalid tool arguments, malicious ticket text, rejection, and repeated approval requests.
- No ticket mutation occurs without a valid server-side approval.
- A rejected or stale proposal cannot execute.
- Repeated application of the same proposal makes at most one change.
- Tool failures and exhausted step budgets produce a clear stop and recovery option.
- Report completion rate, unsupported proposals, latency, and cost against the deterministic baseline. Keep the simpler workflow if the agent does not improve the task.
Deliverables
Provide the sandbox, setup instructions, state diagram, test cases, representative traces, and a failure analysis. Document which decisions remain human-owned. Explain whether planning, memory, or multiple agents add enough value to justify their complexity.
This is an independent project brief; no completed agent implementation is included.
Guided workshop: integrate the agent around trusted state
Start with the shared knowledge service. Keep retrieval and identity enforcement in application code. Add the bounded decision loop from the guarded-registry lab, then durable proposals and approval. Integrate one capability at a time and preserve the earlier deterministic tests.
Use these persistent records:
task: id, principal_id, tenant_id, state, version, remaining_steps, deadline
proposal: id, task_id, ticket_id, ticket_version, text, expires_at, state
approval: proposal_id, proposal_digest, approver_id, decision, decided_at
operation: id, proposal_id, payload_digest, state, remote_result_id
The model can propose a tool and arguments. It cannot choose the trusted principal, increase the task budget, insert approval records, or mark operations applied. Model output and retrieved content pass through the runtime contract just like any other untrusted input.
Integration sequence: first replay scripted decisions against local fixtures; then attach the read-only MCP server; then introduce one real model adapter; then add a durable approval interruption; finally add queue recovery. Run the same task through the framework-free and selected-framework versions. Use multi-agent or computer-use capabilities only where your measured task requires them.
Worked recovery case: a person approves proposal P for ticket version 4. Before execution, another operator updates the ticket to version 5. The worker must reject P as stale and request a new proposal. After a valid operation commits, duplicate queue delivery returns the recorded result rather than applying the text again.
Failure matrix: test a missing ticket, no evidence, unknown tool, malformed arguments, timeout, budget exhaustion, poisoned memory, denied approval, expired approval, changed payload, stale ticket, duplicate delivery, worker crash, and late result after cancellation. For every row record expected terminal state, actual state, mutations, and trace ID.
Portfolio defense: explain why the selected autonomy level improves on the fixed baseline. Show context provenance, exact-action approval, MCP discovery and failure handling, one crash recovery, and the final outcome. An agent that completes a task through an unauthorized route fails even if its answer is correct.
Score runtime boundaries, memory/context, integration, recovery, evaluation, and operations from 0 (absent) to 2 (success and failure reproduced). Require at least 10 of 12, with full marks for boundaries and recovery. This is a course assessment, not a claim of general agent reliability. Live-model metrics and fixture metrics must remain separate in the submission.