A job description works for a person because a person fills its gaps with judgment; an AI agent’s seat card has to close those gaps on paper. “Monitor customer feedback and keep the team informed” gives a new colleague a starting point for a conversation. Given to an agent, it leaves open which feedback it may read, what counts as a finding, whether it may edit a customer record, and who decides when summarising turns into advising.
Seat card is my plain-language name for the role charter in The Agent Dream Team. The book calls a position on the roster a seat and its standing specification a role charter or agent charter; it does not coin “seat card.” It also calls the charter “a one-page job description.” So the distinction here is not between two kinds of paperwork. It is about how much the page must settle before an agent takes the seat.
This is the Roles decision in ROSTER, the book’s framework for running specialist agents in a one-person business. What is a roster? explains the list of named positions; What is ROSTER? covers the whole operating cycle.
Why does a broad job description leave too much open?
A person hired to monitor feedback can ask which customers matter this week. They pick up context from colleagues and recognise that a remark made in passing is not a quote cleared for a client presentation. Their judgment may still be wrong, and a careful employer sets limits anyway. But an ordinary job description assumes that a person will notice a gap and take responsibility for raising it.
An agent can ask for clarification if its workflow tells it to. What it lacks is named in Chapter 2 of the book: agents carry “no social judgment, no legal responsibility, and none of the tacit context a colleague picks up in a corridor.” The chapter’s conclusion is that the written artifacts must be stricter than they would be for a person. If the brief omits the approved source set, the agent may return the task or build a plausible answer from whatever it can reach. You should not leave that choice to the next prompt. The seat card decides in advance what input is sufficient and what happens when it is not.
| Decision | A broad job description might leave open | The seat card should state |
|---|---|---|
| Ownership | Which adjacent requests belong to the role | What the seat owns and explicitly excludes |
| Starting | When the worker needs more context | Required input and the return condition for an incomplete brief |
| Finishing | What a useful result looks like | Output shape and the definition of complete |
| Access | Which available systems to use | Permitted and forbidden tools, checked against actual permissions |
| Boundary | Whom to consult when the task changes shape | The condition for stopping and the person who receives it |
The card does not make human roles boundary-free. It makes the decisions a broad description leaves implicit visible enough to route and review.
Which lines make the seat usable?
Chapter 3 starts with the role name, the handle you use to route and review work. “Research Specialist” is more useful than “Assistant,” but it still leaves the important decisions open. In the book’s composite example, the solo founder Elena has seven types of work running through one chat window. She starts drawing lines between them once she asks what she would put in a job description if she were hiring a person. She then drafts her first three charters (Research Specialist, Draft Editor, Ops Coordinator) by writing the limit before the mandate: first what the role must not do, then what it owns inside that boundary.
An input contract says what must arrive before work starts and when to return a weak brief. An output contract says what leaves the seat and how a reviewer can tell whether it is complete. The tool line names permitted and forbidden access. The escalation rule names the condition under which the role stops and returns the task to the operator. “Ask me if needed” names no condition.
The book’s Research Specialist gathers, synthesises and cites. Its limit says it does not draft, edit, publish or send content, and does not recommend decisions; tasks that require those go back to the founder. The underlying model could write a proposal or an email without difficulty. The seat is not authorised to. That is the difference between capability and authority.
Chapter 3 reduces most role-design problems to three recurring failures: duplicate roles that both claim the same task, overlapping mandates that creep into each other’s territory, and the one-agent-for-everything trap, a generalist with a title and a blank limit. It also names the slow version, mandate blur: a role’s boundaries widen past their specification, usually because borderline tasks get routed to the most convenient session instead of the right one. The diagnostic question is simple: can you route each task in a typical week to exactly one seat on your roster, or to yourself?
The published AI agent charter guide also specifies success criteria and a named reviewer. It uses the CHORUS charter, the same list I use for human operators in teams where people and agents share work, and its layout differs from the ROSTER role charter. In ROSTER those decisions still have homes: the charter sets standing scope, the weekly objective sets this week’s measurable target, and the operator reviews the result.
A worked example: one customer evidence seat
This example is hypothetical. A solo software founder has interview notes about customer onboarding. She wants a short evidence note for her own product review. She does not want the agent to set the roadmap, change customer records or contact customers.
A human-style job description might say: “Track feedback, identify themes, keep the product team informed and maintain accurate records.” That could start a useful conversation with a new hire. For an agent with access to the shared drive and the CRM, it leaves “maintain records” undefined. Does that include changing CRM fields? May the agent call two remarks a trend? May it answer a customer’s email? The founder writes a seat card instead and names the seat after the material that moves through it, as Chapter 3 advises; the chapter’s own example of a good name is “Client Evidence Analyst.”
| Card line | Customer Evidence Analyst |
|---|---|
| Limit, then mandate | Do not recommend roadmap changes, offer discounts, contact customers or edit customer records. Inside that boundary: summarise founder-approved interview notes for a stated question. |
| Input contract | The question, time period and approved notes with stable IDs. Return a brief missing the question or approved source set; do not search for substitutes. |
| Output contract | One page: a direct answer, observations linked to note IDs, contradictions and unknowns. If the notes support no pattern, say so. No invented consensus. |
| Tools | Read the approved notes folder and write a draft to one review folder. No CRM edits, email sending or access to other customer folders. Set the account permissions accordingly. |
| Escalation | Return the task to the founder if a note is outside the approved set, attribution is unclear, or the brief asks for a product decision or external message. Name the decision needed. |
Now try the card against a task. The founder’s hypothetical brief says: “For interviews from 1–7 October, what made setup difficult? Use only approved onboarding notes C01–C12.” It names a question, time period and source set, so the analyst may begin. Suppose notes C04 and C09 mention unclear setup, while C12 says setup was easy. The draft can report those observations with their IDs and flag the contradiction. It cannot turn them into “most customers struggle with setup.” The output contract gives the founder something concrete to check: each claim has a trace, and the limit of the notes stays visible.
Then the founder adds: “Reply to the customer in C09 and offer a discount while you’re at it.” The analyst returns that request. Customer contact and a price decision sit outside the mandate, even if the model could draft a persuasive reply. The useful output is an escalation that names the decision the founder must make. A polished email would be a miss for this seat.
The folders, IDs and output format are design choices in this hypothetical workflow; the book does not prescribe them. The lesson is the boundary: the same role can accept a sourced analysis and return a nearby request without guessing where its authority ends.
Should you point, split or add a seat?
Chapter 10 allows three moves when you extend the base seats. Point a seat at a narrower target, split a seat when two mandates inside it keep colliding, or add a role for work no existing seat covers. The card tells you which move you are making and what must change on paper.
The Customer Evidence Analyst is a pointed Research Specialist seat: the research remit is aimed at approved customer notes. Chapter 10’s rule for pointing applies: “The name changes; the boundary does not.” The narrower name grants no new power to send emails or advise on pricing. The same chapter calls gathering sources and synthesising them the classic collision inside the Research Specialist seat. If that collision shows up here, the founder could split the seat: one charter delivers an approved source set, the other accepts that set as its input. That handoff must be written, and the split is a design option to test, not proof that two agents will produce better work.
A task outside every charter does not automatically justify a new role. Under these rules the discount request belongs to the founder. If a new type of recurring work really has no seat, draft its charter and count the review it will add to your week before activating it. The book’s Roster Capacity Budget is the author’s planning heuristic, not a measured headcount limit. How many AI agents can one person supervise? works through that count.
Where do objectives, permissions and review fit?
Chapter 2 treats the charter as the design decision and a system prompt as one way to encode it: if you switch platforms tomorrow, the charter travels with you. Chapter 4 adds a weekly objective, which turns the standing job description into a weekly contract: what this role must deliver now, by when, and to what standard. For the hypothetical analyst, that might be: “By Thursday, deliver a one-page note on this week’s approved onboarding interviews; link each observation to a note ID and list contradictions.” Next week the question changes. The limit on customer contact does not.
The operator must then check the work against the output contract and the objective. A tidy note can still misread an interview. A charter can still forbid tools the account has not actually restricted. Set permissions in the system, inspect the source links and keep the final review with the person who owns the decision. The card records those decisions; it does not carry them out for you.
Try this today
Pick one agent or automation you already use. Find one real past task whose original brief and accepted output you can inspect. Choose a task near the edge of its role if you have one.
- Draft the card. Name the seat. Write its limit first, then its mandate, required input, complete output, permitted and forbidden tools, and the exact condition for returning work to you. Check the real account permissions before calling the tool line true.
- Run the chapter’s fit-test. Can you state the mandate in one sentence? Does the limit exclude at least two types of activity? Does the output contract define “complete”? Does the escalation rule name a specific condition? Chapter 3 also asks whether you can read the whole charter aloud in ninety seconds. Revise any line that fails.
- Replay the task on paper. Would the original brief have met the input contract? Would the accepted output have met the output contract? Should the role have accepted, returned or escalated the task? Write down the first ambiguous decision and repair that line before the next run.
One past task shows whether the card describes your work; it does not certify the agent. The book’s fuller Agent Interview uses three to five real tasks from the last month, including one at the edge of the charter, before any live work. If today’s check exposes a blank limit or an unnamed return route, you have found the decision you were leaving to the next prompt.
Cite this:Seat card vs job description: what an AI agent needs in writing.Len P. van der Hof. https://lenvanderhof.com/en/blog/seat-card-vs-job-description/ ·