How to Write a Project Brief for a Custom AI Employee

Start the brief with one job, not a role. A custom AI employee works best as a configured workflow with defined responsibilities, inputs and permitted actions, so name a single task that happens often enough to observe and is bounded enough to review. For that task, list what goes in, what comes out, which systems or documents supply the information, which actions the system may take on its own, and what counts as done. That last item matters most: without an agreed definition of success, there is nothing to test against later.

Keep three operations separate throughout: reading, drafting and execution. Reading a record, preparing a recommendation and changing something in a business system are different acts with different risk, and Microsoft’s Copilot Studio documentation draws the same line between generative answers grounded in connected knowledge sources and generative actions that call APIs, run flows or trigger connectors. Say which side each step of your workflow sits on. Wherever it moves from preparation to action, name the approval point: who signs off, what they see before approving, and what happens if they decline. A prepared action must never be confused with a completed one.

Check the brief by walking through an example request. Consider an illustrative scenario: a new service request arrives, the agent checks whether the necessary details are present, asks for whatever is missing, and prepares a structured record for the responsible team. It may create or update a task only if the configured integration permits it, while any commercial commitment stays with an authorised person. Treat such a walkthrough as a proposal to test, not as evidence of anything already deployed — if your version leaves a field undefined or grants an action nobody approved, the brief is not ready.

Give each connected system its own permissions entry: record types touched, who owns the access, supported operations, and explicit exclusions. Pair it with a recovery plan, since its purpose is to tell the responsible team what to do when something goes wrong. Decide in advance what occurs when information conflicts, credentials expire or an integration is unavailable, and require a record that lets the responsible team determine what actually happened. Completed work must not repeat simply because a later step failed.

Close with milestones instead of a delivery date. Scope agreed, integrations checked, pilot reviewed, release accepted — each gate is driven by data readiness, system access and acceptance results, not by the calendar, so assign an owner to every gate, including recovery responsibility once the workflow is running. Keep expansion separate: new responsibilities earn their own scope, permission review and acceptance checks rather than riding along with the first release. If you want a neutral reference for the questions those gates raise, NIST’s AI Risk Management Framework organises them under four voluntary functions: Govern, Map, Measure and Manage.