Free template, no sign-up
One-page AI agent summary template
One page for a boss, a security reviewer or a finance approver, covering what an AI agent is allowed to do, what it costs and whether it's worth it. You might know this as an agent card, agent charter or scope document. A filled-in copy can run to about two printed pages, so send the summary on its own if your reader wants one page and keep the rest as backup. The template is free to copy, change and use, including at work.
By Chris Faulkner, Agent Blueprint. Version 1, published November 1, 2026. Agent Blueprint is the method NowGentic uses in its paid agent delivery work, so we have a stake in this format. It's new and hasn't been widely used yet.
What goes on the page
Summary
The decision, what it's allowed to do, what it costs and whether it's worth it, for a reader who stops here.
1. Purpose
The job it does, and what's out of scope.
2. Authority
What it can do alone, what needs approval, what it must never do, its tools and data, the model and data handling, whose account it runs as, its limits on money and usage, and how mistakes get undone.
3. Proof
How it was tested, what counts as passing, and where each action is recorded.
4. Owner
Who's accountable, who can stop it and how, who gets told when it acts, and who reviews its work.
5. Cost
Volume, usage per run in tokens, credits or dollars, monthly cost including human time and mistakes, and cost to build.
6. Promise
One number with a baseline, target and date, the failure that must not get worse, when to stop, the alternative, the ROI math, and how much of it is real cash.
7. Result
Filled in at the check-back: what was measured, whether its setup still matches this page, and the decision.
The blank template
# [Agent name]: one-page summary Version [1], [date]. Stage: [Proposed, Approved, Live or Measured]. ## Summary - Decision needed: [build, pilot, keep running, expand or stop] - Allowed: [what it does alone, what needs approval, its hard limits] - Costs: [cost to build, and monthly cost including human time] - Worth it: [cash impact, time freed up, payback, how confident you are] How to fill this in: when you don't know an answer, write `[Open]` with who decides and your suggested default. Don't guess a number. End every rule with `Enforced by:` and the setting or system that makes it true, or `Not enforced:` and why. An instruction the agent is only asked to follow counts as not enforced. ## 1. Purpose - Does: [the job, for whom, in one or two sentences] - Doesn't do: [what's out of scope] ## 2. Authority - Can do on its own: [actions]. Enforced by: [setting or system] - Needs human approval: [actions, and who approves]. Enforced by: [setting or system] - Must never: [actions]. Enforced by: [setting or system] or Not enforced: [why] - Tools and data: [each connection, and whether it reads or changes things] - Model and data handling: [vendor and model, how sensitive the data is, where it goes] - Runs as: [whose account or which service account, with what permissions] - Limit on what it can spend or move: [amount and period]. Enforced by: [setting or system] - Limit on its own usage bill: [amount and period]. Enforced by: [setting or system] - If it makes a mistake: [how it gets undone, or that it can't be] ## 3. Proof - Tested with: [cases, including attempts to manipulate it and the failure that matters most] - Passes when: [result, and who set that bar] - Results: [link or Open] - Every action is recorded in: [where to look] ## 4. Owner - Accountable person: [name and role] - Who can stop it, and how: [person, and the exact switch]. Enforced by: [setting or system] - If it's stopped, the work goes to: [person or team] - Who gets told when it acts: [person or channel, or nobody] - Who reviews its work: [person, how often, hours a month] ## 5. Cost - Volume: [runs per month], [measured or estimated] - Usage cost per run: [tokens, credits or dollars], [measured or estimated] - Monthly cost: [usage + fixed costs + human review + upkeep + expected cost of mistakes] - Cost to build: [amount or Open] ## 6. Promise - The one number: [metric, and where it's measured] - Today: [baseline, or "no baseline yet, measuring until (date)"] - Target and date: [value by date] - This means: [cash saved, staff time freed up or better service] - Must not get worse: [the failure that matters more than the gain] - Stop or rethink if: [the result that ends it, set in advance] - Instead of this: [what you'd do without the agent, such as nothing or simpler automation] - Other value: [revenue, quality or risk reduced, if time saved doesn't capture it] - ROI math: [runs handled x minutes saved per run / 60 x hourly cost = monthly value; monthly value - monthly cost = monthly net; cost to build / monthly net = payback in months; repeat at half the target] - Cash or time: [how much of the net is real cash, and how much is staff time that only becomes cash if spending drops] - Whose estimates these are: [name] ## 7. Result Leave this empty until the check-back. - Check-back date: [usually 90 days after going live] - Measured: [the number from section 6, and the failure rate] - Still matches this page: [yes, or what changed in its tools, permissions or settings] - Decision: [keep, change or retire], by [name], on [date] Approved by: [name, role, date]
A filled example
# Refund Helper: one-page summary This example is made up. The company, people and numbers are fictional. Version 1, 2026-11-01. Stage: Proposed. ## Summary - Decision needed: pilot for 90 days. - Allowed: refunds up to $100 on its own. Anything larger goes to a person, and it can't pay a different card. - Costs: $6,000 to build and $986 a month, including $590 of staff time and an estimated $288 in mistakes. - Worth it: probably, but mostly as staff time. It frees up about 50 hours a month, saves no cash unless spending actually drops, and pays back in about 5.4 months at full target and about 15.7 at half. Confidence is low until the pilot measures it. ## 1. Purpose - Does: reads customer refund requests, checks them against the order and the refund policy, and issues refunds up to $100 for the support team. - Doesn't do: chargebacks, fraud cases, or anything where the customer disputes the policy. ## 2. Authority - Can do on its own: issue a refund up to $100 on a verified order. Enforced by: the refund service, which rejects anything over the cap. - Needs human approval: refunds over $100, and a second refund on the same order. Enforced by: the refund service, which sends these to the support queue. - Must never: refund to a different card or account. Enforced by: the refund tool, which has no destination field. - Must never: promise a customer anything outside the policy. Not enforced: this is only an instruction to the agent. The monthly review in section 4 looks for it. - Tools and data: order lookup (reads), refund policy (reads), support tickets (reads and changes), refund tool (changes). - Model and data handling: a commercial model API under a company contract. It sees customer names, order details and request text, but no card numbers. - Runs as: the service account refund-helper, with no admin rights. - Limit on what it can spend or move: $3,000 in refunds a day. Enforced by: the refund service, which stops and alerts the support lead. - Limit on its own usage bill: $150 a month. Enforced by: the spending limit on the model vendor account. - If it makes a mistake: ticket changes can be reversed. A paid refund usually can't be, so it's counted as a cost in section 5. ## 3. Proof - Tested with: 200 past requests, 20 messages trying to talk it into a bigger refund, and repeat requests for the same order. - Passes when: 95% of decisions match what the support team decided, with zero refunds over the cap and under 1% paid in error. The support lead set this bar. - Results: Open. Testing finishes before the pilot starts. Decides: Dana Reyes. - Every action is recorded in: the refund service log and the ticket history. ## 4. Owner - Accountable person: Dana Reyes, support lead. - Who can stop it, and how: Dana or the on-call engineer, using the refund_agent_enabled switch. Enforced by: the refund service. - If it's stopped, the work goes to: the support queue. - Who gets told when it acts: the customer by email, and #refund-log for the team. - Who reviews its work: the support team checks 1 in 10 refunds, about 10 hours a month. ## 5. Cost - Volume: 1,200 requests a month, measured over the last three months. - Usage cost per run: $0.04, estimated until the pilot measures it. - Monthly cost: $986, made up of $48 usage (1,200 x $0.04), $60 hosting, $350 review (10 hours x $35), $240 upkeep (4 engineering hours x $60), and an estimated $288 in mistakes (1% of 720 requests x $40 average, assuming every handled request is paid). - Cost to build: $6,000. ## 6. Promise - The one number: support hours spent on refunds each month, from the ticket system. - Today: 120 hours (1,200 requests at 6 minutes each). - Target and date: 70 hours by 90 days after going live, including 10 hours of review. - This means: staff time freed up. No one's job or budget changes on this page. - Must not get worse: refunds paid in error stay under 1% of what the agent issues. The team's own error rate is Open, and the pilot's first month measures it. Decides: Dana Reyes. - Stop or rethink if: errors go over 1%, or the agent handles under 30% of requests after 90 days. - Instead of this: keep handling refunds by hand, or auto-approve only the simplest cases with a fixed rule. The rule wasn't priced for this page. - ROI math: 720 requests handled x 5 minutes saved / 60 x $35 an hour = $2,100 monthly value; $2,100 - $986 = $1,114 monthly net; $6,000 / $1,114 = about 5.4 months payback at full target. At half the target, value is $1,050, cost is $667 (half the review and mistakes) and net is $383, so payback is about 15.7 months. A 90-day pilot won't pay back on its own. - Cash or time: cash goes down by about $396 a month (usage, hosting and mistakes). The cash never pays back by itself. The $1,750 of freed-up support time (50 hours) is capacity for other work and becomes cash only if spending drops, and it's what covers the $240 of upkeep. - Whose estimates these are: Dana Reyes, for the 60% handled and the 5 minutes saved per request. ## 7. Result Empty until the check-back. - Check-back date: 90 days after going live. Approved by: Open. Decides: Sam Ito, head of customer operations.
Common questions
Is there a standard format for this?
Not that we know of, and this template isn't one either. Model cards describe a model rather than one deployed agent. The NIST AI Risk Management Framework is broad risk guidance. If your company has its own review form, use that and borrow what's missing from here.
Is this the same as an A2A Agent Card?
No. In the Agent2Agent protocol, an Agent Card is a machine-readable file agents use to find and talk to each other. This page is for the people deciding whether an agent should be allowed to run. Some teams call this kind of document an agent card, charter or scope document.
How do I show that a rule is real?
End each rule with what enforces it, such as a permission, a service limit or an approval setting. If it's only an instruction to the agent, write that it's not enforced. A reader can then see which limits would hold if the agent got something wrong.
How is ROI calculated?
Runs handled x minutes saved per run / 60 x hourly cost gives monthly value. Subtract monthly cost, including human review, upkeep and the expected cost of mistakes, to get monthly net. Divide the cost to build by that to get payback. Freed-up staff time is capacity, and it only becomes cash if spending drops, so the page keeps the two apart. If time saved doesn't capture the value, use a different formula and show the math. The inputs are estimates until measured, and section 7 records what really happened.
Want the agent to fill in part of it?
If the agent can read its own tool list, you can have it draw what it can read and change. That gives you a starting point for section 2, in the agent's own words, so check it before you rely on it.