How to Write SOPs an AI Employee Can Actually Use

§ 01The AI Employee SOP at a Glance

Use this table as a completeness check, not as a substitute for the procedure itself.

§ 02What Makes an SOP Usable by an AI Employee?

A usable SOP reduces interpretation at the points where interpretation can change the business outcome.

It does not attempt to script every word. It defines a controlled path through a task:

1. A recognized event starts the work.
2. Preconditions establish whether the work may proceed.
3. Required inputs are retrieved from approved sources.
4. Actions transform those inputs into an output or state change.
5. Decision rules route variable cases.
6. Evidence makes the route reviewable.
7. Authority rules determine whether the worker may execute, request approval, or stop.
8. Completion criteria prove that the task is done.
9. Handover rules transfer any remaining ownership.

OpenAI’s practical guide to building agents recommends starting from existing operating procedures, defining clear actions, and capturing edge cases as they appear. That approach works when the existing procedure is treated as raw material rather than assumed to be executable instructions.

An SOP is not a goal

A goal defines the bounded result the role should pursue. An SOP defines how to carry out a recurring procedure within that role.

For example: Goal - maintain a qualified research queue with no unowned high-priority request. SOP - triage a newly submitted research request.

The AI employee goals guide covers outcomes, constraints, non-goals, and stop conditions at the role or workstream level. An SOP inherits those limits and adds the operating path.

An SOP is not a job description

The AI employee job description defines the role, accepted outcomes, scope, authority, and accountability. A single role can contain several SOPs. Do not repeat the entire role contract inside each procedure; reference its current approved version.

An SOP is not a context pack

The AI employee context pack identifies the authoritative policies, schemas, examples, vocabulary, and source systems that govern the role. The SOP references the exact context components required for the procedure.

This separation matters. A policy may change without changing the sequence of an SOP. A procedure may change without changing the source hierarchy. Keeping each artifact owned and versioned prevents a copied paragraph from becoming an accidental second policy.

An SOP is not an application tour

“Open the CRM, click Contacts, and look around” describes an interface. It does not explain what decision is being made or what evidence proves completion.

Describe the business operation first. Add tool-specific instructions only where the interface or API contract affects correctness.

§ 03Choose One Procedure and One Accepted Outcome

Begin with a narrow unit of work.

Good candidates have a recurring trigger; a recognizable starting state; a repeatable result; a limited number of decision branches; observable inputs and outputs; a named owner; enough volume or importance to justify standardization; and consequences that can be bounded with permissions and approvals.

Poor first candidates combine several business processes, depend on undocumented negotiation, or end with a high-impact decision that only a qualified person can make.

For example, replace “handle sales” with “qualify one inbound demo request,” not ownership of the entire sales cycle. Replace “do support” with “classify and route one new ticket,” not a promise to resolve every customer problem. Replace “manage research” with “produce a cited change brief for one approved question,” not a mandate to research anything useful.

The same boundary applies to higher-impact work. An AI employee might reconcile one approved report against source records, assemble an evidence packet for a reviewer, or validate one draft against a publication checklist. It should not make financial decisions, select candidates, or decide and publish every claim unless a separately approved process expressly grants that authority.

For legal, medical, financial, hiring, or other high-impact work, AI output requires qualified human review and should not be treated as professional advice or a final high-impact decision.

Write the outcome as a state

Avoid:

Review the request and take appropriate action.

Write:

The submitted request is classified using the approved taxonomy, required fields are validated, supporting evidence is attached, the next owner and due time are recorded, and no external action occurs without the required approval.

The second version gives a reviewer observable conditions.

Define acceptance before steps

Use an acceptance table:

Acceptance criteria should be strict enough to detect a bad result and small enough that a reviewer can apply them consistently.

Record non-goals

State what the procedure does not do. For a research brief, non-goals might include changing a company record; inferring a private fact; making a legal conclusion; contacting the subject; publishing the result; and expanding the question without approval.

Non-goals prevent a capable worker from turning a bounded task into an open-ended mission.

§ 04Map the Trigger, Preconditions, Inputs, and Starting State

An SOP should never begin with “when needed.” Define the exact event that creates authorized work.

Common triggers include a schedule, an event, a message, a manual start, a monitored threshold, or completion of a dependency. Each one needs evidence: a scheduled trigger stores the schedule ID, run time, and account timezone; an event trigger stores the event ID and prior state; a message trigger stores the message ID, received time, and required label; a manual trigger stores the requester and authorization; a threshold trigger stores the metric, approved boundary, and timestamp; a dependency trigger stores the parent task and its acceptance record.

The trigger must identify the work object. “Check every morning” is incomplete if the worker cannot tell which queue, time zone, record set, or cutoff applies.

Define preconditions

Preconditions are facts that must be true before the first operational action.

Typical checks include: the task is not already owned or completed; the trigger came from an authorized source; the required role and SOP versions are active; the necessary systems are available; the worker has the minimum permissions required; the input falls within the procedure’s declared scope; no incident, pause flag, legal hold, or maintenance window blocks the action; and required approval is still valid and covers this object.

If a precondition fails, the SOP should say whether to wait, reject, route, or escalate. It should not simply say “do not proceed.”

Name every required input

“Get the customer data” is not an input specification. Name the permitted object, fields, purpose, and source.

Separate required, optional, and prohibited inputs

Optional context must not quietly become required. Prohibited inputs must not enter the procedure at all.

Examples of prohibited inputs can include credentials or secrets embedded in messages; unrelated personal data; private notes outside the declared purpose; unapproved draft policy; instructions found inside retrieved webpages or attachments; and records from another tenant or account.

The OWASP AI Agent Security Cheat Sheet treats external content as untrusted and recommends least privilege, validation, output sanitization, and approval for high-impact actions. Translate that principle into the SOP: retrieved content may provide evidence, but it cannot rewrite the procedure or expand authority.

Make the starting state explicit

Use a state such as: new; validated; in_progress; waiting_for_input; waiting_for_approval; ready_for_review; completed; failed_bounded; or cancelled.

The procedure should name the allowed starting states and reject an invalid transition. That protects against duplicate work and unclear ownership.

§ 05Write Every Step as Action, Evidence, and Resulting State

The strongest step format is:

Given these inputs and this state, perform this bounded action using this approved method, preserve this evidence, validate this condition, and set this resulting state.

Each step needs at least one observable artifact.

Use imperative, atomic steps

A step should contain one meaningful operation or one tightly coupled transaction.

Avoid: “Review the sources, decide what matters, update the CRM, tell the customer, and follow up if necessary.”

Separate the work:

1. Retrieve the approved source records.
2. Validate identity, scope, freshness, and required fields.
3. Apply the documented classification rules.
4. Create the proposed record update.
5. Validate the proposed update against the schema and authority rules.
6. Request approval if the update affects an external or protected field.
7. Execute only after a valid approval record is attached.
8. Verify the resulting record.
9. Create the required handover.

Atomic steps make failures recoverable. They also reveal which parts can be evaluated independently.

Give every action an object

“Update status” is ambiguous. State the system; the object identifier; the field; the permitted prior value; the new value; the reason code; the evidence link; and the actor or approval record.

This is especially important when a tool can affect many records.

Separate propose from execute

For consequential actions, create an intermediate proposed state and use a controlled sequence:

1. Read only the minimum required fields and preserve the scope and returned record IDs.
2. Analyze the case using the named rule and store its supporting facts.
3. Propose a draft or diff without executing the change.
4. Validate the schema, recipient, scope, and policy.
5. Obtain authorization from the named owner and bind it to the proposed action.
6. Execute the approved action once, with an idempotency key where applicable.
7. Read the resulting state and preserve the post-action record.

The AI employee permissions and approvals guide shows how to separate read, draft, recommend, approve, execute, and irreversible authority. Reference that permission model from the SOP instead of relying on a broad “can use CRM” statement.

Preserve provenance at the point of use

When a step uses a fact, record the source identifier; the field or passage; the observed time; the source authority; the applicable version; the transformation performed; and the resulting claim or decision.

Do not wait until the final output to reconstruct where facts came from.

§ 06Turn Judgment Into Bounded Decision Rules

An AI employee can handle variable cases, but the SOP must show where discretion begins and ends.

Replace “use judgment” with a decision question; the permitted evidence; named categories; thresholds; precedence; unknown behavior; conflict behavior; approval conditions; and the resulting route.

For example, a qualification decision can ask whether the request belongs on the standard path. It may use only the submitted fields and current approved account fields. All three required conditions must be true; a missing fact remains unknown rather than receiving a confidence-based guess. The system-of-record field outranks a user-entered label for that decision. A positive result continues to standard processing, a negative result closes with a documented reason, and an unknown goes to manual verification. Any external notification still requires the declared approval.

Prefer rule identifiers

Give important rules stable IDs: eligibility.standard.v4; source-precedence.account-status.v2; approval.external-send.v3; or stop.sensitive-data.v1.

The run record can then show which rule produced the route.

Define unknown as a valid result

An unknown is not a failure of intelligence. It is a correct result when the available evidence does not support a conclusion.

Write:

If either required field is missing, stale, or conflicting, set the decision to unknown, preserve the values and provenance, and route the item to the account owner. Do not infer the value from free-text notes.

This prevents confident gap-filling.

Distinguish ambiguity from conflict

• Missing: required information is absent.
• Ambiguous: information has more than one reasonable interpretation.
• Conflicting: two sources give incompatible values.
• Stale: information exists but is outside the approved freshness window.
• Out of scope: the case does not fit the declared procedure.

Each condition may require a different owner and response.

Use examples as tests, not hidden policy

Examples help show how a rule applies. They should include an accepted case; a rejected case; an unknown case; a boundary case; a conflicting-source case; and an unsafe case.

Label each example with the policy or rule version that supports it. When an example conflicts with current policy, policy wins and the example should be retired.

Anthropic’s guidance on building effective agents recommends simple, composable patterns and evaluator feedback where criteria are clear. A decision table plus test cases is easier to evaluate than a paragraph asking the worker to be thoughtful.

§ 07Define Tools, Permissions, and Approvals Inside the Procedure

The SOP should reference a role permission profile and narrow it further for the procedure.

Define tool inputs and outputs

For every tool operation, state the allowed operation; required parameters; prohibited parameters; object scope; maximum batch size; the expected result; timeout; retry policy; idempotency behavior; and validation after execution.

“Use the email tool” is too broad. A sending step should define sender identity, recipient derivation, allowed recipient domains, disclosure requirements, template or schema, attachment rules, approval, and delivery verification.

Bind approval to the exact action

An approval record should include the approver identity; the covered object; the proposed action or diff; the permitted channel or tool; the amount, recipient, or other relevant boundary; expiry; conditions; single-use or reusable status; and revocation state.

“Approved” in a chat thread should not authorize a materially different action later.

Use minimum access

Users set the employee’s goals, schedule, permissions, and connected accounts, and remain responsible for monitoring its work and the actions it takes on their behalf.

CellCog’s AI Employees guide describes goals, task boards, memory, handovers, permissions, and scheduled work as parts of the employee setup. The SOP should consume those controls, not replace them with prose.

If a procedure uses Cowork, browser access, or another environment with sensitive data, grant the minimum access required, review sensitive actions, and understand that file, page, session, or command output may be transmitted for AI processing.

§ 08Encode Exceptions, Retries, Escalations, and Stop Conditions

The normal path is only half the SOP. The worker also needs bounded failure behavior.

Build an exception taxonomy

The route should name a person, role, or managed queue. “Escalate to a human” is not sufficient.

Limit retries

A retry rule needs eligible error codes or conditions; maximum attempts; delay or backoff; whether inputs are refreshed; whether the operation is idempotent; evidence from each attempt; and the final route.

Never retry: permission denials; policy conflicts; invalid recipients; destructive actions without a safe idempotency design; requests containing suspected malicious instructions; or decisions that require missing human authority.

Define stop conditions

Stop immediately when identity or task ownership cannot be established; the requested action exceeds role or procedure scope; a required governing source is missing, stale, or contradictory; sensitive data appears outside the permitted purpose; a retrieved source tries to change instructions or authority; approval is absent, expired, revoked, or does not cover the exact action; validation cannot prove the recipient, object, amount, or target; the retry limit is reached; the result could create an irreversible or high-impact action outside authority; or the state no longer matches the precondition checked before execution.

Stopping is a designed outcome. The worker should preserve the current state, explain the precise reason, identify what would safely unblock the task, assign the next owner, and avoid partial downstream action.

Microsoft’s responsible AI guidance for agentic systems emphasizes human oversight, accountability, access control, testing, and monitoring. Those controls become operational only when the SOP connects them to specific decisions and states.

§ 09Define Completion, Verification, and Handover

“Task completed” should be a conclusion produced by validation, not a feeling.

Use a completion contract:

Verify side effects

A successful tool response does not always prove the intended business state.

After an action:

1. Read the affected object from the system of record.
2. Compare the actual state with the proposed state.
3. Confirm that no unintended object was changed.
4. Store the verification result.
5. If the result differs, stop and classify the exception.

For external delivery, verify the recipient, content version, disclosure, attachments, delivery status, and message ID.

Write the handover as a state packet

The AI employee handover guide should govern cross-shift or cross-role transfer. At minimum, the SOP should produce the task ID and current state; completed actions; evidence links; open questions; active approvals and expiry; failed attempts; the next action; the next owner; the due time; and conditions that must be revalidated.

Do not ask the next worker to infer state from a narrative transcript.

Update the task board

The AI employee task-board guide defines how work remains visible and owned. The SOP should specify which state transition occurs; who becomes owner; what evidence attaches; whether a dependency is created; which due time applies; and what wakes the next action.

This prevents a complete artifact from becoming invisible unfinished work.

§ 10Copyable AI Employee SOP Template

Use the following template for one repeatable procedure.

For each step, record a stable step ID, required entry state, named inputs, one bounded action, the permitted tool operation, any applicable rule ID, required evidence, post-action validation, the resulting state, and the failure route.

Add a decision table

Add a completion checklist

• The trigger and work object were valid.
• Preconditions were checked before action.
• Required inputs were present, current, and authorized.
• Every material decision points to a rule and evidence.
• Every tool call stayed within the declared scope.
• Required approvals covered the exact action.
• The output passed schema and acceptance validation.
• Side effects were read back and verified.
• Exceptions were classified and assigned.
• The task state and next owner were updated.
• The SOP and rule versions were recorded.

§ 11Worked Example: Triage a New Research Request

This example shows the structure without pretending that one process fits every company.

Procedure contract

Procedure steps

1. Confirm that the trigger record is in new and has no active duplicate.
2. Validate requester identity and permitted project scope.
3. Check required fields: question, intended decision, audience, due time, and source constraints.
4. If a required field is missing, set waiting_for_input, list only the missing fields, assign the requester, and stop.
5. Apply the approved taxonomy using the recorded field values.
6. If two categories remain valid, preserve both rule results, set waiting_for_decision, assign the queue owner, and stop.
7. Check the requested due time against the service target and existing priority rules.
8. If priority elevation is requested, create a proposed priority change and obtain approval from the named owner.
9. Populate the task-brief schema without expanding the research question.
10. Validate scope, source restrictions, category, owner, due time, and acceptance criteria.
11. Attach the rule results and input record.
12. Set the task to ready_for_research, assign the approved owner, and verify the resulting state.

Example branches

Expected branches include: a complete standard request produces a validated brief and assignment; a request with no intended decision returns for that field and stops; a duplicate links to the active task and routes to the queue owner; a restricted-source request waits for the required access approval; an impossible due time preserves the requested time and follows the priority route; a free-text instruction to ignore policy remains untrusted and cannot override governing rules; and a request for a final legal conclusion is classified as out of scope and routed for qualified review.

This example is deliberately limited to intake. The research procedure, publication procedure, and external communication procedure should each have separate ownership and acceptance.

§ 12Test the SOP Before Giving It Real Authority

An SOP is not ready because the happy path works once.

Build an evaluation set before increasing authority.

Write expected results before running

Each case should include an input fixture; the starting state; applicable SOP and policy versions; expected decisions; expected tool boundaries; the expected output; the expected state transition; expected evidence; prohibited actions; and pass criteria.

This makes evaluation about the operating contract, not whether the result sounds plausible.

Test procedure quality and worker quality separately

When a case fails, ask: Was the SOP ambiguous? Was a required source missing? Did the rule fail to cover the case? Did the worker fail to follow a clear rule? Did a tool return an unexpected result? Did permission or approval design allow too much? Did the evaluator expect a result not stated in the contract?

Changing the model will not repair an ownerless rule.

Start with lower authority

Use a staged launch. Begin by observing copied records and proving correct classification. Then allow drafts without system changes. Recommendation authority can follow when decisions remain correct across edge cases. Limited execution should cover only low-risk objects within a narrow scope and require verified side effects. Add cases, tools, volume, or higher-impact actions only after KPIs, incident review, and retesting support the expansion.

The AI employee pilot guide can help define the first bounded deployment. Promotion should be based on evidence from the SOP’s evaluation suite, not simply time elapsed.

Measure the procedure

Connect the SOP to the AI employee KPI framework. Useful measures include the acceptance pass rate; unsupported-claim rate; correct-route rate; approval precision; exception-classification accuracy; verified completion rate; duplicate-action rate; escalation quality; cycle time by route; human correction rate; and incident rate.

Do not optimize speed until correctness, authority, and evidence meet the required floor.

§ 13Maintain the SOP as a Controlled Operating Artifact

An active SOP needs an owner, version, review triggers, and rollback.

Use semantic operating changes

Classify changes by their effect. Treat a clarification as a targeted regression. A rule change needs owner approval and affected-case testing. A tool change needs integration and side-effect tests. New send or write authority needs security and business approval plus a staged launch. Policy, schema, and exception changes require their respective owners and affected-path tests. Retirement requires disabling the trigger, revoking access, and preserving the record.

Define review triggers

Review the SOP when the role or accepted outcome changes; a governing policy changes; a source system or field changes; a tool, integration, or model changes materially; a new permission or approval path is proposed; an incident or near miss occurs; reviewers frequently correct the same step; an exception appears repeatedly; a KPI crosses its control limit; or the scheduled review date arrives.

NIST’s AI RMF Core calls for ongoing monitoring, documentation, accountability, and risk treatment across the lifecycle. A change log connected to evaluation cases is the practical mechanism for one procedure.

Record every active version

A run record should identify the SOP, role, goal, policy, schema, tool contract, and evaluation versions, plus the time each became effective. Together, those fields establish the procedure text, inherited authority, desired outcome, governing rules, accepted output, expected interface, and tested cases.

A task record should allow a reviewer to reconstruct which versions governed the run.

Roll back safely

A rollback plan should state the last approved version; which triggers to pause; which permissions to revoke; how in-progress tasks are classified; whether executed side effects require review; how downstream owners are notified; and what evidence is preserved for incident analysis.

Do not delete the failed version or its run records. Retain them according to the applicable record and privacy rules.

§ 14How CellCog Maps to a Machine-Usable SOP

CellCog describes an AI Employee as a standing agent configured for a role. The product supports goals, KPIs, permissions, approval expectations, memory, handovers, a task board, schedules, and configured wake conditions. These capabilities correspond to different parts of the operating design.

The CellCog AI Employees page positions the product around hiring an AI employee for a role. The SOP is the procedure-level layer beneath that role: it turns recurring work into a path that can be observed and reviewed.

Keep controls outside prose where possible

Do not rely on the article-like SOP alone to enforce system permissions; recipient allowlists; field restrictions; approval gates; batch limits; schedule limits; sensitive-data filters; or task-state transitions.

Configure enforceable controls in the relevant systems, then reference them by version in the SOP.

Use the task board as operational state

The SOP should read the current task state before acting and update it after each meaningful transition. Memory can support continuity, but it should not be the only record of ownership, approval, due time, or completion.

Make delegation explicit

If an AI Employee delegates a subtask, define the bounded requested outcome; permitted sources; prohibited actions; the required output schema; the deadline; authority; evidence requirements; and the return route.

The parent remains responsible for validating the returned artifact against the original SOP.

§ 15Common SOP Mistakes

Writing a policy essay instead of a procedure. Background can help a reviewer, but the worker still needs a trigger, state, action, evidence, and route. Move lengthy policy explanation into an owned source and reference it.

Automating the undocumented exception path. If the team cannot agree on how to handle a common exception, the SOP is not ready for independent execution. Route the exception to an owner and learn from the decisions before encoding a rule.

Hiding several procedures in one document. Intake, fulfillment, approval, publication, and follow-up often have different owners and risks. Split them at state and accountability boundaries.

Using examples as authority. An old approved output can show format. It should not override current policy, customer state, price, recipient, or legal requirement.

Giving tool access without operation limits. Access to a system does not define which records, fields, actions, or batch sizes are permitted. Use the AI agent guardrails guide to connect prevention, detection, approval, and recovery controls to the procedure.

Allowing silent completion. An artifact is not complete if it lacks evidence, validation, state update, or downstream ownership. Define all four.

Retrying every failure. Repeated attempts can duplicate messages, writes, charges, or records. Retry only declared transient failures and use an idempotency design.

Treating escalation as failure. A correct stop with a precise handover is better than an unsupported action. Track unnecessary escalations separately from required ones.

Copying the SOP into several prompts. Copies drift. Keep one approved procedure ID and version, retrieve it at run time, and record which version governed the task.

Expanding scope after a successful pilot. More volume, new data, new tools, different recipients, and higher-impact actions are separate authority changes. Each needs explicit review and affected-case testing.

§ 16Final Checklist

Before activating an AI employee SOP, confirm:

• One trigger creates one bounded unit of work.
• The accepted outcome and non-goals are observable.
• Preconditions and allowed starting states are explicit.
• Required, optional, and prohibited inputs are separated.
• Source authority, freshness, conflict, and unknown behavior are defined.
• Every consequential step produces evidence or a state transition.
• Judgment is expressed through bounded rules and routes.
• Tool operations, object scope, batch size, and retries are limited.
• Approval binds to the exact proposed action.
• Exceptions have named owners and safe next actions.
• Stop conditions prevent unsupported or irreversible work.
• Completion includes output, validation, side-effect verification, and handover.
• Evaluation covers normal, missing, conflicting, stale, sensitive, and malicious cases.
• Versioning, review triggers, rollback, and retirement are owned.

If those conditions are true, the SOP is more than documentation. It is a reviewable operating boundary for recurring work.

To put that boundary into production, define the role first, convert one high-value procedure, test it with lower authority, and then configure the relevant task, context, permission, approval, and KPI controls for a CellCog AI Employee.