“Add an agent” is not a feature brief. It leaves the team to infer the task, the customer, the allowed actions, and the point at which the work is finished. Those missing decisions tend to reappear during implementation, often as disagreements about what the product was supposed to do. A better brief starts with the work a person wants completed.
The template below is designed for a bounded feature, such as preparing a draft response or organizing a request for review. It is an editorial planning tool, not a claim about an existing Agentmatic product. Use it to align product, engineering, operations, and the person who will review the output before choosing how much agent behavior the feature needs.
Begin with the user’s situation
Describe the moment that brings the user to the feature. Include what they already have, what is missing, and what they need next. “An account manager has approved meeting notes and needs a follow-up draft” is specific enough to discuss. “Users want to be more productive with AI” leaves too many possible tasks open.
Name the person who benefits and the person who bears the review burden. They may be different people. If a feature prepares material for a supervisor, include the supervisor’s needs in the brief. A useful output for the requester can still be awkward for the person expected to approve it.
State the current method in a few sentences. This gives the team a comparison and may reveal that the real problem is missing source information or an unclear approval process. A feature should not be expected to solve a policy disagreement that the organization has not resolved.
Define the trigger and input contract
Write exactly what starts the feature. It might be a button pressed by an authorized user, a record entering an approved state, or a scheduled review of a bounded queue. Avoid phrases such as “when appropriate,” which push an important decision into implementation without explaining how it should be made.
List required inputs and acceptable optional inputs. For a follow-up draft, required material could include approved notes and a selected recipient. Optional material might include a tone preference. If a required input is absent, define what the user sees and whether any work begins. Missing information should have a designed response.
Identify the source of each input. Distinguish user instructions from material the system is asked to read. That distinction matters when external or retrieved content contains instructions of its own. The brief should make clear which sources are authoritative for the task and which are simply evidence to be considered.
Specify tools by operation
A list of connected applications is not enough. Write the permitted operations: read an approved note, retrieve a contact, save a draft. Then state the operations outside scope. If sending a message requires approval, make that a separate action with a separate condition. Avoid granting a broad capability simply because the integration supports it.
The OWASP AI Agent Security Cheat Sheet recommends limiting tool permissions and testing security-relevant changes. In a feature brief, that becomes a request for explicit access boundaries and named tests. The engineering design will need to implement those boundaries; prose alone does not enforce them.
Also identify whose authority is used. A feature acting for an individual user may need a different access model from a shared background task. The product team should raise this question early rather than assume that all users can reach all connected records. Permission failures need an understandable user-facing outcome.
Make the handoff an actual state
If a person must review the result, define what “ready for review” contains. The reviewer might need the draft, original notes, proposed recipient, and any unresolved questions. Give the state a clear name that does not imply the external task is already finished. A prepared message is still different from a sent message.
Write the available decisions. The reviewer could approve, edit, reject, or ask for more information. Specify what happens after each one. If an edit changes the content that was approved, decide whether another approval is needed. If a request is rejected, define whether the feature may try again automatically or must wait for a new instruction.
The NIST AI RMF can help teams organize wider questions about roles and evaluation. It is voluntary guidance rather than a ready-made approval policy. The feature owner still needs to decide who reviews this output and what responsibility that person can realistically carry.
Write completion criteria before the demo
Completion should be observable. For a drafting feature, a criterion might be that the draft preserves the approved facts and marks missing information for review. Avoid “produces a high-quality response” unless the team also defines how quality is assessed. Vague criteria make it difficult to tell a successful feature from a persuasive example.
Separate different kinds of correctness. The right recipient, accurate source facts, appropriate tone, and absence of unsupported commitments are distinct checks. A single overall score may hide a serious problem in one category. Decide which failures block release and which can be handled through an explicit review process.
Include examples that should stop the workflow. A request with no approved notes should not pass merely because the system generates plausible text. A request outside scope should receive a useful explanation or route to a person. Correctly declining to act can be the expected result of a test.
A worked brief for a draft follow-up
User situation: An account manager has finished a customer meeting and approved the notes. The next task is to prepare a follow-up message that another team member can review.
Trigger: The account manager chooses “Prepare follow-up” on an approved note and selects an existing contact. The feature does not start from an unapproved note or an unselected recipient.
Inputs: The approved note version, the selected contact, and an optional writing preference. The feature may read the note and the contact record. It may save a draft attached to the request. Sending is outside this feature’s scope.
Output and handoff: A draft appears beside the note, with unresolved details listed separately. The reviewer can edit or reject it. The screen says “Draft ready for review,” and the request remains open until the reviewer makes a decision.
Exceptions: Missing notes produce a request for approved material. An unavailable contact record stops preparation. Repeating the trigger on the same request shows the existing draft or asks whether a new version is intended, according to the chosen product design.
Evaluation: Use an ordinary note, an incomplete note, conflicting dates, and a note containing an unrelated instruction. Check factual preservation, recipient handling, visible exceptions, and the absence of an unapproved send action. Record reviewer edits so the team can understand the remaining burden.
Add ownership and change conditions
End the brief with an owner for the feature and an owner for its evaluation examples. Decide what happens when a connected system changes or the underlying model configuration is updated. A brief is more useful when it identifies the conditions that require another review, rather than disappearing after the first release.
Keep a short record of decisions that were deliberately deferred. Perhaps the first version saves drafts but does not send them, or supports one source type while others remain under investigation. That record helps the team expand the feature without accidentally treating an unbuilt behavior as part of the original promise.
To use the template today, choose one feature and fill in the trigger, tools, handoff, and finish in ordinary language. Then ask a colleague to describe what the feature would do with an incomplete request. If the colleague has to guess, revise that part of the brief before adding more implementation detail.