How to Write an AI Agent Project Charter on One Page

An AI agent project charter is a one-page document that states what the agent is for, who owns it, what it may and may not touch, and what evidence will show it works. It is written and signed before any build starts. Use a fixed set of fields, keep each answer to a few sentences, and name one person who approves it. If a field cannot be filled in, that gap is the real work still ahead.

Key takeaways

• A charter is a decision tool, not a specification. It lets one accountable person say yes, no or not yet.
• Eight fields are enough: purpose, owner, users and channels, memory and tools, boundaries, approval points, success evidence, and review and exit.
• Boundaries should be written as three lists: what the agent does alone, what it does only with approval, and what it never does.
• Success evidence must be chosen before the work begins, with a named reviewer and a defined way of collecting it.
• The charter is a living page. Changes to it should go through the same approval path as changes to the agent.

What is an AI agent project charter, and why keep it to one page?

A charter is the shortest document that lets a business owner decide whether an agent project should begin. It answers questions that otherwise get settled informally, usually after something has gone wrong: who is responsible, what is the agent allowed to do, and how will anyone know it is helping.

One page matters because length hides disagreement. A twenty-page plan can be approved by people who each read a different part and imagined a different agent. A single page forces the sponsor, the operations lead and the technical team to agree on the same sentences. If two people read the purpose line and describe different outcomes, you have found a problem at the cheapest possible moment.

The charter is not a business case, which argues for investment, and it is not a contract. It sits between them. The business case says why the company should do this. The charter says what exactly is being done and under whose control. A statement of work then turns the charter into obligations between a company and a provider. When the charter is clear, the statement of work becomes much easier to write and to check.

Which fields belong on the page?

Eight fields cover what a leader needs to decide. Each one has a short prompt so the answer stays concrete.

• Purpose: one sentence naming the single role the agent fills and the outcome it serves. Avoid lists of ambitions.
• Owner: one named person in the company who is accountable for the agent's behavior and can approve changes. A team name is not an owner.
• Users and channels: who talks to the agent, through which channels (email, chat, a shared inbox), and who does not.
• Memory and tools: what the agent is allowed to remember and which systems it can read or write, each with the level of access.
• Boundaries: what it does alone, what needs approval, what it never does.
• Approval points: the specific moments where a human must confirm, and who that human is.
• Success evidence: what will be observed, by whom, over what period, and what result counts as good enough.
• Review and exit: when the charter is reviewed, and what conditions lead to pausing or ending the work.

Resist adding fields. Timelines, vendor details and architecture diagrams belong in other documents. If you want a companion that shows how the pieces connect, an architecture map is a better home for that detail than the charter.

The discipline of starting small is consistent with how Anthropic describes building agents in its engineering guidance: find the simplest solution that works and add complexity only when it demonstrably helps. A charter that names one role makes that discipline practical.

How do you write purpose and owner so they hold up?

A good purpose line has a verb, an object and a beneficiary. For example: draft first replies to supplier delivery queries so the purchasing team can review and send them faster. It does not say transform purchasing or improve communication. It could be tested by someone who has never heard of the project.

Two checks help. First, can you describe the role as a job? If you can write a short job description for the agent, with duties, inputs, outputs and a supervisor, the purpose is probably specific enough. Second, can you say what the agent is not for? A purpose that excludes nothing usually means the scope has not been chosen.

The owner line is where many projects quietly fail. An owner is a person with authority over the work the agent touches, not the person who is most enthusiastic about AI. The owner approves boundaries, receives incident reports, signs off on changes and attends the reviews. If the owner changes jobs, the charter needs a successor named the same week. Many companies discover too late that an agent depended on one champion, which is why continuity planning when a champion leaves belongs in the owner conversation from the start.

It also helps to separate the owner from the operator. The owner is accountable for what the agent does for the business. The operator, whether an internal person or a provider, keeps it running. Writing both on the page prevents the situation where everyone assumes the other party is watching.

How do you set boundaries and approval points?

Boundaries are the part of the charter that protects the company, so write them as three explicit lists rather than as general statements about being careful.

• Does alone: actions that are reversible, low in consequence and easy to review later, such as drafting text, summarizing a thread or looking up a record.
• Does with approval: actions that change something outside the agent or reach a person outside the company, such as sending a message to a customer, updating a record or booking something.
• Never does: actions that stay with people regardless of how well the agent performs, such as changing payment details, deleting data or granting access to others.

For each item in the middle list, name the approver and the channel where approval is requested. An approval point that depends on someone remembering to check is not a control. It needs a place where the request appears and a person who has agreed to answer it.

The tools and memory field supports the same logic. Write down every system the agent can reach and the narrowest access that lets it do its job. OWASP's authorization guidance describes the same principle in security terms: grant the minimum permissions needed and deny by default. The charter should state that principle as a rule for this agent, and it should say who reviews access over time. A permission review is the recurring practice that keeps the page honest.

One more item belongs here: what the agent should do when it is unsure. The answer is rarely to guess. Most charters say the agent asks the owner's designated reviewer, states what it could not determine, and takes no action until answered.

What counts as success evidence?

Success evidence is the field most often left vague, and vagueness here makes every later review a negotiation. Evidence is something that can be observed, collected by a named person and compared with a starting point. Satisfaction in general terms is a feeling, not evidence.

A workable entry has four parts:

• The observable signal: for example, the share of drafted replies that reviewers send with only light edits, or the time a request waits before a first response.
• The starting point: how that signal looks today, measured before the agent begins, so improvement is a comparison and not an impression.
• The method: a sample of real cases reviewed by a named person on a fixed rhythm, with a written note of what was found.
• The decision rule: what result means continue, what means adjust, and what means stop. The owner sets this before results exist.

Setting the decision rule early is what keeps the evidence honest. If the bar is chosen after the results arrive, it tends to move toward whatever was achieved. The guide on defining success criteria for a pilot goes further on choosing signals. Anthropic's writing on evaluating agents makes a related point: define tasks with clear conditions for passing, and read real transcripts, not only summary scores.

Also include one line about harm. Along with the signal that shows value, name the signal that shows trouble: wrong information sent, an approval skipped, an unexpected tool call. The NIST AI Risk Management Framework organizes risk work around governing, mapping, measuring and managing. A charter does not need to adopt the framework, but its owner, boundaries and evidence fields cover the same ground in small form.

Finally, say which stage the work is in. A proof of concept, a pilot and production each prove something different, and the charter should claim only what the current stage can show. The article on what each stage must prove helps here.

How do you fill in the charter in one working session?

The charter works best when written together, in a single session of focused conversation, not circulated as a form. The sequence below keeps the discussion moving.

• Gather the owner, one person who does the work the agent will support, and whoever manages the systems involved.
• Write the purpose sentence first. Do not move on until everyone reads it the same way.
• Name the owner and the operator. If either is unclear, stop and resolve it now.
• List the systems and information the agent would need, then cross out everything that is not necessary for the first version.
• Draft the three boundary lists. Argue about the middle list most, because that is where real judgment lives.
• Choose the success signal, the starting point, the reviewer and the decision rule.
• Set a review date and write the exit conditions, including who can pause the agent without asking permission.
• Read the page aloud. Anything that cannot be said plainly gets rewritten.
• Have the owner sign and date it, and store it where the team can find it.

An illustrative scenario: a distribution company wants an agent to help its purchasing team with supplier delivery queries. The purpose line says the agent drafts first replies from the order records and the team reviews and sends them. The owner is the purchasing lead. Under tools, the agent can read order records and shared inbox threads but cannot edit orders. Under approval, every outgoing message needs a purchasing team member. Under never, it does not change quantities, dates or payment terms. The success evidence is a weekly sample of drafted replies reviewed by the lead, compared with how the team handled the same kind of query before. The exit condition says that any message sent without review pauses the agent until the cause is found. Nothing in this page is complex, yet every future disagreement now has somewhere to point.

If the work ever needs to stop, a charter with clear exit conditions also makes it easier to pause or end a pilot without losing what was learned.

How does Be Human handle the charter in practice?

Be Human treats the charter as the output of a first engagement, not a preliminary form. The engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, and those answers are written on the page the owner signs. During managed operations, the charter becomes the reference for monitoring, recurring evaluations and permission reviews. Changes to the agent, its tools or its boundaries are requested and approved against the page, so the document stays current and the owner stays in control.

Frequently asked questions

How long should an AI agent charter be? One page is the target, and it is a useful constraint, not a rule for its own sake. If an answer needs a full page by itself, the scope is probably too large for a first agent and should be split. Supporting detail can live in linked documents as long as the charter itself stays readable at a glance.

Who should sign the charter? The owner signs, because that person is accountable for the agent's behavior and for approving changes. It helps to have the sponsor who funds the work and the person who manages the connected systems acknowledge it as well. A charter nobody is willing to sign is a sign the project is not ready.

When should the charter be updated? Update it whenever the role, the tools, the boundaries or the success evidence change, and review it on the date you set at the start. Treat edits as controlled changes with an approver and a note of what changed and why. A charter that drifts from reality is worse than none, because people trust it.

Does a small company need a charter for a single agent? Yes, and the small size is a reason it takes little effort. A single page agreed in one conversation prevents the most common problems: unclear ownership, access that grew without review, and results nobody can judge. The same page also gives you a starting point if you later choose to broaden the work across teams.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.