Custom Agents
How to write a custom AI agent project brief
A structured brief for scoping a custom AI agent or workflow: business outcome, process, approved data, systems, rules, human review, security and measurement.
12 minute read Updated August 2026 By the ScoChat product team
Most AI projects stall because the brief describes a technology rather than a piece of work. “We want an AI agent” is not scopeable; “we want inbound supplier invoices matched to purchase orders, exceptions routed to finance, and a decision trail we can audit” is.
This brief is the document our solution architects use before estimating an engagement. You can fill it in yourself, and it is equally useful if you never work with us: it forces the eight decisions that determine whether an agent is buildable, safe and measurable.
1. Define the business outcome, not the feature
Start from the change you want in the business. An outcome is something an operations lead already tracks: hours returned, backlog cleared, response time reduced, error rate lowered, opportunities recovered, capacity added without headcount.
- Which team or process is affected, and who owns it today?
- What happens now, and what does it cost in time or money?
- What would “better” look like in the numbers you already report?
- What is explicitly out of scope for the first release?
Write it as one sentence
“We want to reduce the time between a customer request arriving and a qualified response leaving, without adding a person to the queue.” If the sentence needs the word AI to make sense, it is not an outcome yet.
2. Map the workflow as it really runs
Document the current process step by step, including the parts nobody wrote down: the spreadsheet someone maintains, the manager who is asked before an exception is approved, the two systems that never reconcile.
- 01
Trigger
What starts the work — an email, a form, a schedule, a record change, a phone call?
- 02
Steps
Each action taken, who performs it and what information they need to perform it.
- 03
Decisions
Every point where a judgement is made, and the rule or experience behind it.
- 04
Output
What must exist when the work is finished — a record, a document, a message, a status.
Automation candidates are the steps that are repetitive, rule-shaped and information-bound. Steps that require relationship judgement, negotiation or legal accountability usually stay with people — supported by the agent, not replaced by it.
3. List the approved data the agent may use
An agent is only as trustworthy as the information it is allowed to read. Name the sources explicitly, and name the ones it must never touch.
- Documents and knowledge: policies, manuals, price lists, contracts, product data
- Records: CRM, ERP, ticketing, inventory, scheduling, finance systems
- Ownership: who approves each source, and who keeps it current
- Sensitivity: personal data, regulated data, commercially confidential material
- Exclusions: sources the agent must not read, and data it must never output
Freshness is part of correctness
Decide how often each source is refreshed and what should happen when the agent hits information it cannot verify. “I do not have an approved answer for that” is a correct response.
4. Identify the systems, APIs and permissions
Integration is usually the largest engineering variable in an estimate. For every system the workflow touches, capture whether it can be reached programmatically and under what authority.
- System
- Name, vendor, version and internal owner.
- Access
- Documented API, partner API, database, file exchange, or screen-only.
- Direction
- Read only, write, or both — and which specific objects.
- Credentials
- Which service account is used, granted by whom, with least privilege.
- Limits
- Rate limits, quotas, maintenance windows and sandbox availability.
Where no API exists, say so early. There is usually a path — an export, a queue, a middleware layer, a manual review step — but it changes the design and the cost.
5. Write the business rules and the exceptions
Rules make behaviour predictable. Exceptions are where projects fail, because they are the cases people handle from experience and never document.
- Hard rules the agent may never break, in plain language
- Thresholds — values, discounts, dates or risk levels that change the path
- Known exceptions and how they are handled today
- The fallback when the agent is uncertain, and who receives the work
6. Decide where a human stays in the loop
Autonomy is a dial, not a switch. A sensible first release automates preparation and keeps approval with a person, then widens as evidence accumulates.
- 01
Suggest
The agent drafts; a person approves every item.
- 02
Approve by exception
Routine cases proceed; unusual ones queue for review.
- 03
Act with audit
The agent completes the work and every action is logged and reversible.
Auditability is a requirement, not a feature
For each automated action, record the input, the decision, the data used and the outcome. Without that trail you cannot debug the system or defend it internally.
7. Set the security and governance boundaries
- Least-privilege service accounts scoped to the objects the workflow needs
- Where data is processed and stored, and which regions are acceptable
- Retention: what is kept, for how long, and what is discarded immediately
- Which model providers are permitted, and whether any content may leave your tenancy
- Internal approvals required before go-live — security, legal, data protection
These constraints belong in the brief rather than in a late review. They frequently determine architecture, and they are far cheaper to satisfy at design time.
8. Agree how it will be measured
Define the baseline before the build starts, because after go-live nobody can reconstruct it honestly. Pick two or three measures tied to the outcome in section one.
- Volume: items processed, calls handled, requests resolved
- Time: cycle time before and after, and hours returned to the team
- Quality: exception rate, correction rate, escalations
- Adoption: how much of the eligible work actually flows through the system
Measurement also drives iteration. The first release exposes real edge cases; the review cadence is where an agent becomes genuinely reliable.
Custom AI agent brief checklist
- Business outcome written as one sentence, with a baseline
- Current workflow mapped: trigger, steps, decisions, output
- Approved data sources named, with owners and exclusions
- Systems, APIs, permissions and rate limits documented
- Business rules and known exceptions written down
- Human review model chosen for the first release
- Security, residency and retention boundaries agreed
- Two or three success measures defined before build
Next step
Bring one real process to the conversation.
Bring the process, call flow or content problem behind the guide and we will tell you what is buildable and how we would measure it.