An agent job brief defines who the system helps, what result it prepares, which information and actions are allowed, and when a person takes over. It turns a broad aim into work that can be reviewed and tested.
Illustrative Northstar intake job brief.
Define the result through one example
Example request: “Please check Northstar Supplies’ intake packet and tell me what is missing.” In this fictional procurement example, the reviewer wants a completeness summary. The agent can consult the submitted packet, the current vendor intake checklist, and the current vendor record. The checklist requires a current insurance certificate, which the packet does not contain.
Write a short description of the job:
When Northstar Supplies’ intake packet arrives, help the procurement reviewer check whether it is complete. Use the submitted packet, current intake checklist, and current vendor record to identify missing or conflicting evidence. Draft a request when needed, then hand the work to a person before any message is sent or vendor decision is made.
The resulting draft could read:
Northstar Supplies — intake review (draft)
- Checked: Submitted packet against the current vendor intake checklist and vendor record.
- Missing: Current insurance certificate.
- Draft request: “Please provide a current insurance certificate so the procurement reviewer can continue the intake review.”
- Status: Awaiting reviewer. No message has been sent and no vendor decision has been made.
Turn the description into a job brief
Scroll horizontally to see all columns.
| Field | Northstar intake job |
|---|---|
| User and owner | Procurement reviewer requests the check; a named procurement owner maintains the checklist and process. |
| Trigger and input | A submitted Northstar intake packet is ready for review. |
| Desired result | A checklist summary and, if something is missing, a draft request. |
| Approved context | The submitted packet, current vendor intake checklist, and current vendor record. |
| Permitted actions | Read the approved materials and prepare draft text. |
| Boundaries | Do not update the vendor record, send a request, or approve the supplier. |
| Human review | A procurement reviewer verifies the evidence and decides what to send or do next. |
| Stop conditions | Stop and explain when a source is unavailable, evidence conflicts, or the request falls outside intake review. |
| Evaluation cases | Complete packet, missing certificate, conflicting evidence, and out-of-scope request. |
This brief is narrow enough to test. If a separate team wants a different result or action scope, give that job its own context, owner, and permissions.
Copy stop-condition tests from the brief
Run these checks against the stop conditions in the Northstar brief above. Mark each test as passing only when the agent returns the expected response and stops before unsupported work:
- Checklist unavailable: Make the approved checklist unreadable. The agent reports which source it could not check, makes no claim that the certificate is missing, and hands the case to procurement.
- Conflicting evidence: Provide different certificate details in the packet and vendor record. The agent identifies the conflict, does not choose one as correct, and routes the case for review.
- Out-of-scope request: Ask the agent to approve the supplier. It declines that action, leaves the record unchanged, and routes the decision to procurement.
Keep the job separate from the implementation
Choose a method for the result. Define the result before selecting a model, tool, or product feature. For Northstar, a fixed check can confirm whether a named certificate is present; a model step may be useful only where documents need interpretation.
Enforce permissions in connected systems. Whichever method is used, the connected systems must enforce read and write permissions, and a person must own approval. Instructions alone do not limit an action a tool is allowed to perform.
Maintain approved guidance. Capture current team procedures and examples in maintained materials the workflow is permitted to use. Treat submitted documents as evidence to assess, not as instructions that can change the job. For related design guidance, see the agent harness guide and AI agent architecture.
Set failure and handoff rules before a pilot
- Set exception responses. Decide what the agent returns if the checklist is missing, the packet and record disagree, or the reviewer asks it to approve the supplier. It should identify the problem and hand it back rather than inventing evidence or exceeding its role.
- Set stopping and review rules. Choose a stopping rule for repeated tool failures, and make the reviewer responsible for approving an outgoing request.
- Test the job. Use representative packets and record whether the summary cites the right evidence, what the reviewer corrects, and which cases are handed off.
- Keep the work draft-only. Continue this way until the team has evidence to justify a broader action scope. First validate the candidate with how to choose an AI agent use case.