Agent Job Cards: Definition of Done Before You Grant Autonomy

At the point of granting CMS access, a marketing operations lead needs more than a convincing draft. The permission request should come with a job card: which content brief the agent can read, which draft fields it can change, and what evidence makes the work complete. Without that artifact, “prepare this page” leaves the agent to interpret both the assignment and its boundaries.

In Eric’s Leveling Up recruiting example, the artifact is a candidate screen with concrete criteria: two promotions at two companies and an average tenure of three years. The classifier returns a judgment and confidence against those criteria. That sequence gives marketing operators a useful starting point: define the decision before granting the ability to act on it.

Quick Overview

An agent job card is a written contract for one bounded assignment. It specifies inputs, outputs, definition of done (DoD), evaluation gates, permissions, rollback, and ownership before write access exists. Start with that contract, then select the workflow and model that can satisfy it. A fluent answer alone does not establish that the assignment is safe to delegate.

• Define required fields and allowed output types, including an explicit exception result.
• Make completion checks observable: evidence, destination, scope, and policy compliance.
• Separate eligibility, score, and confidence so uncertainty cannot disappear inside an average.
• Document the restore path and accountable owner before expanding permissions.

Why autonomy without a job card is just a chat demo

A demo shows that an agent can produce something plausible. A job card tells an operator whether that output satisfies a business assignment. “Improve our SEO content” leaves the agent choosing the target, interpreting the brief, deciding what counts as improvement, and potentially changing a live asset. Those are separate decisions with different consequences.

Write the job as a narrow action against a named artifact. “Create a staging draft from an approved brief” has a destination and a permission boundary. “Own organic growth” does not. Keep business outcomes in the strategy, but make the agent’s completion criteria inspectable without waiting for rankings or revenue.

Eric’s point that a better model still needs a better workflow changes the buying decision here. Do not purchase a stronger model to compensate for undefined inputs or an absent restore path. First determine whether the assignment can be specified. Then evaluate models against that specification.

This page covers the authorization contract before execution. Single Grain’s five-step reliable marketing bots framework addresses runtime quality loops. A job card supplies the acceptance criteria those loops need; it does not replace them.

Worked scene: write inputs, outputs, and DoD before write access

For a proposed Single Grain-style content operation, take one bounded assignment: turn an approved SEO brief into a staging draft. The marketing operations lead starts with the brief, destination CMS record, approved evidence, ICP description, and brand rules. This is a design example, not a reported client deployment.

Type the inputs. The brief needs an ID and approval state. The destination needs a record ID and environment. The evidence needs source URLs and the claims each source supports. The ICP and brand rules need identifiable versions. Missing approval or an ambiguous destination produces an exception, rather than an invitation to infer intent.

Type the outputs just as carefully. The result contains draft fields, a claim-to-source map, check results, and either a staging record reference or an exception reason. Scope excludes publishing, changing redirects, altering templates, and editing unrelated pages. The permission grant should enforce those exclusions rather than relying only on instructions.

Eric’s recommendation to set evaluation criteria before agents act adds specific gates to this card: check whether an equivalent page is already live, whether the draft fits the approved ICP, and whether its claims and language satisfy brand and policy rules. Define the evidence for each gate. A duplicate check should identify the existing URL or record what inventory was searched.

Completion means the required fields exist, the evidence supports the claims, the gates are satisfied, and the output stays inside the staging boundary. Before granting that write permission, specify recovery: preserve the prior draft, identify the changed fields, and provide a restore operation. If the destination cannot support a usable restore path, keep the output as an exportable draft.

Worked scene: score yes/no and confidence against the card, then decide

In the Leveling Up discussion of Jev, Eric describes classifiers seeing definition of done through yes/no judgments, scores, and defined confidence levels. His recruiting example supplies the concrete requirements: two promotions at two companies and average tenure of three years. The screen scores the candidate against those requirements with confidence before the process moves forward.

The useful sequence is criteria first, candidate evidence next, then a classified result. The numbers belong to that recruiting example. They are not marketing performance benchmarks or evidence of classifier accuracy.

For the marketing card, this changes the output contract. Return a yes/no answer for each mandatory gate, an evidence reference, a score only where a rubric exists, and a separate confidence field. Do not let a strong writing score offset a failed policy requirement. Mandatory checks remain mandatory.

Define confidence labels operationally. “High” might require direct evidence in the approved input; “uncertain” might mean conflicting sources or missing fields. These are proposed rubric labels, not measured probabilities. Set the qualifying threshold using reviewed examples. Until that threshold has a defensible meaning, route uncertain cases to an exception queue without write access.

Eric’s DoD observation therefore changes two recommendations: put the checklist in writing, and encode uncertainty as an output the workflow can handle. A classifier forced to choose yes or no despite missing evidence creates a brittle contract.

Job card checklist (inputs, outputs, DoD, rollback, owners)

Keep the card short enough to inspect and specific enough to test. Anthropic’s guidance on building effective agents favors simple, composable patterns over unnecessary complexity. Apply that principle by giving one card one bounded job, rather than assembling an elaborate agent system around an ambiguous objective.

• Job and exclusions: name the artifact, permitted action, destination, and forbidden changes.
• Inputs: specify required fields, types, provenance, approval state, and missing-data behavior.
• Outputs: define the result structure, evidence references, and exception format.
• Definition of done: state observable checks and which failures block completion.
• Evaluation gates: include already-live checks, ICP fit, brand/policy, and confidence handling.
• Rollback: record the prior state, restore operation, trigger, and person responsible for recovery.
• Owners: assign a named business owner, permission owner, and exception-queue owner.

Make human approval one explicit boundary. Eric’s observation that people still provide taste, review outputs, and manage workflows means the card must name the individual who accepts, edits, or rejects the work before autonomy expands. For this staging assignment, publication remains outside the grant. “Marketing” is not a named ship gate.

The NIST AI Risk Management Framework supports accountability and measurement as management responsibilities. Use Single Grain’s marketing-agent pipeline RACI guidance to distinguish responsibilities, then put actual names on the card. Pair the restore requirement with kill-switch and managed-agent controls; neither an owner field nor a stop button substitutes for recovery.

Walk away from automation when the team cannot agree on acceptable output, necessary evidence is unavailable, or consequential changes cannot be recovered. Keep that job manual or narrow it. The wrong purchase is a stronger model asked to resolve an organizational disagreement disguised as a prompt.

Single Brain installs the system; Single Grain runs it when you need the team

Single Brain is the AI implementation OS for job-specific agents, evaluations, and kill switches. The starting artifact should be a bounded job card, followed by the workflow and controls required to enforce it. That keeps implementation tied to an inspectable assignment instead of a general promise of autonomy.

Hire Single Grain to install and run that system when you need the operating team without staffing it yourself. Start with one job and bring its inputs, destination, acceptance criteria, and recovery constraints. Talk to Single Grain about defining the contract before granting access.