Practice — Agent Harness Engineering (13 questions)

An internal agent that files and updates tickets caused an incident: it closed 340 tickets in one run, using a credential that also had delete permissions, and nobody noticed for two hours. The postmortem produced a mixed list of proposed fixes:

1. "Give the agent a ticket-system credential that can comment and update but not delete."
2. "Reword the system prompt to say the agent should never close more than a handful of tickets without asking."
3. "Cap any tool result at 2,000 tokens."
4. "Require a human confirmation before any bulk operation touching more than 10 records."
5. "Route ticket triage through a fixed classification step first, and only send genuinely ambiguous tickets to the agent."
6. "Emit a live per-run event stream so on-call sees an agent making hundreds of state changes while it is happening."

For each item: name which layer owns it (model/prompt, harness, or orchestration), and say whether it would actually have prevented or limited this incident. Then state which single fix you would ship first and why.

You are specifying the harness for an agent that helps engineers write and apply database migrations. It can read the schema, read the application code, write migration files, run migrations against a local database, and — on request — apply a migration to staging. Engineers run it interactively; a nightly job also runs it unattended to keep a shadow schema in sync.

1. Define the permission tiers, saying precisely what each tier can do and what it takes to enter it.
2. Identify which actions must be gated regardless of tier, and justify the criterion you used to pick them.
3. The nightly unattended run cannot prompt a human. Explain how it gets enough authority to be useful without becoming the weakest link in the whole design.