How to Write an AI Employee Job Description

§ 01The AI Employee Job Description at a Glance

A short description can contain every section. Length is not the goal. Operational completeness is.

§ 02What Is an AI Employee Job Description?

An AI employee job description is a versioned specification for a standing software role. It tells the worker what outcome to pursue and tells the surrounding organization how to supply, constrain, inspect, and manage that work.

It serves four audiences at once:

1. The role owner uses it to approve the business outcome and boundaries.
2. The implementation team uses it to configure instructions, context, tools, triggers, and permissions.
3. The reviewer uses it to judge outputs and escalation behavior.
4. Security, legal, privacy, and system owners use the relevant fields to assess access and consequence.

It should be readable by a person and translatable into configuration. That second requirement changes how it is written.

“Be resourceful and support the marketing team” may sound reasonable in a human job ad. It leaves software with unanswered questions: Which team requests enter the queue? Which sources are authoritative? May it contact customers? May it publish? What makes an output complete? What should happen when sources conflict? Who resolves a brand or legal question? How long should it wait? Which state should the task enter while waiting?

A usable description answers those questions before live work.

It is not a prompt

A prompt may guide one interaction. The job description defines a continuing role across many tasks, shifts, triggers, and changes. It remains the reference when individual prompts conflict, a source becomes stale, a reviewer is unavailable, or the worker encounters work near its boundary.

The final implementation may convert parts of the description into instructions, policy rules, schemas, evaluations, approval controls, or dashboard fields. Do not force every control into prose if the platform can enforce it.

It is not an HR document

Do not include compensation, benefits, equal-opportunity language, career progression, or human personality requirements unless a separate legal or communications process genuinely requires them. Avoid claims that the software “replaces a full-time employee” or carries legal responsibility.

Human job descriptions assume a person can use broad experience, social context, and managerial access to resolve ambiguity. An AI role needs more explicit source, action, evidence, and escalation boundaries.

The principle is simple: replace traits with observable operating behavior.

§ 03Design the Role Boundary

1. Start With One Outcome, Not a Job Title

Choose a functional role name only after you can write its mission in one sentence:

This role owns [observable recurring outcome] for [queue or audience] on [schedule or trigger], using [approved sources], and routes [named exceptions or decisions] to [human owner].

Examples:

• This role owns a source-linked competitor-change brief for the strategy team every Monday, using the approved competitor registry, and routes pricing conflicts or unsupported claims to the research lead.
• This role owns first-pass classification and policy-grounded drafts for three allowlisted support categories, and routes refunds, security issues, account changes, and policy exceptions to the support lead.
• This role owns weekly reconciliation of the operating dashboard from approved project and financial exports, and routes missing, inconsistent, or materially changed data to the operations owner.

Weak versions include “AI marketing manager,” “help with support,” and “improve operations.” A title names a domain. It does not define an accepted outcome.

Use the best tasks for AI employees framework to confirm that the underlying work is recurring, digital, observable, bounded, and recoverable. If a fixed rule can perform the work reliably, use workflow automation. If a person should initiate every request, an on-demand assistant may be the better shape.

Define the owned unit

The description needs a countable unit of work: an accepted weekly brief; a reviewed account packet; a correctly triaged ticket; a reconciled dashboard; an approved content outline; a completed vendor evidence record; or a resolved data-quality exception.

Do not use “task” as the unit unless every task has the same completion and acceptance rules. A role may start ten tasks while producing no accepted business outcome.

Name the customer of the work

Every role needs a downstream user or system that can accept the result. Identify who requested the outcome; who uses the deliverable; who judges acceptance; who owns policy; and who receives unresolved work.

These may be different people. A research lead can own the role while a product leader accepts the briefing. A support supervisor can review drafts while a security team owns incident policy.

Keep the first role narrow

Do not combine “research competitors, write strategy, publish articles, update CRM, run outreach, and report revenue” because one platform can technically touch all those systems. The combined role has several outcomes, audiences, evidence standards, permissions, and consequences.

Split it when a responsibility requires a different acceptance rubric; source hierarchy; authority tier; escalation owner; risk class; cadence; or downstream customer.

The job description should fit one coherent accountability loop.

2. Define Intake, Triggers, and Priority

A standing role needs a lawful way for work to enter. “Be proactive” is not an intake design.

List every allowed trigger: a scheduled time; a new item in an approved queue; a message to the worker’s inbox; a system event; a threshold or KPI condition; an assignment by a named person; or a delegation from an authorized role.

For each trigger, define scope, priority, deduplication, quiet periods, and the safe behavior when capacity is exceeded.

The role also needs a queue-capacity rule. If 200 items arrive when it can review 50 during a shift, should it take the highest-priority 50; process oldest first; sample; ask for capacity; defer with a visible state; or reject new intake?

Silence creates hidden backlog. The description should require an observable state for work that is accepted, deferred, blocked, expired, duplicated, or rejected.

Define who may assign work

An inbox or task board is not automatically an authority channel. State which people, systems, or agent roles may create assignments and which fields an assignment must contain.

A valid assignment may require a request ID; an allowed task type; a business purpose; the input location; a due time; a sensitivity label; an acceptance rule; the requester; an approver, if needed; and an expiration time.

Reject or escalate assignments that ask the worker to exceed the current job description. “The CEO emailed it” should not silently expand data or action rights.

3. Write Responsibilities as Observable Contracts

Responsibilities should describe behavior a reviewer can inspect.

Use this structure:

When [valid trigger] occurs, use [approved sources/tools] to [bounded action], produce [deliverable] with [required evidence], then move the work to [next state or owner].

Compare:

Each responsibility should make five things visible:

1. Trigger: why the work started.
2. Action: what the role is expected to do.
3. Output: what artifact or state change it produces.
4. Evidence: how a reviewer can reconstruct the basis.
5. Next state: where ownership goes after the action.

OpenAI’s practical guide to building agents recommends clear, structured instructions, explicit actions, and handling for edge cases. A job description is where the organization defines those requirements before they become runtime instructions.

Separate decisions from actions

“Decide and publish” often hides two authority levels. Break compound responsibilities apart:

1. Identify a possible material change.
2. Retrieve and compare evidence.
3. Classify it against the rubric.
4. Prepare a claim.
5. Request approval if required.
6. Publish through a controlled channel.
7. Verify the result.

The role may be allowed to perform steps 1-4 independently while a person owns step 5 and the system releases step 6 only after valid approval.

Include completion and postcondition

A tool call succeeding does not prove the business action succeeded. If the role updates a system, state the required postcondition: the CRM field equals the approved value; the message appears in the correct thread; the document exists in the approved folder; the dashboard value matches the source total; the task is assigned to the correct next owner; or no external action occurred after an approval expired.

Require the worker to verify the postcondition or record that verification was unavailable.

Limit the number of primary responsibilities

For a first role, three to seven primary responsibilities are usually easier to evaluate than a long catalog. This is a practical design preference, not a universal platform limit.

Group minor mechanics under one responsibility only when they share the same outcome, evidence, permission, and reviewer. If the list keeps growing, the role likely contains multiple jobs.

4. Write Non-Goals, Refusals, and Stop Conditions

Non-goals protect the role from adjacent requests that sound helpful but change its risk.

For a competitive-research employee, non-goals might include: no publication; no contact with competitors, customers, or employees; no access outside approved sources and subscriptions; no inference of personal or confidential information; no final strategic recommendation; no change to the source registry; and no unrelated market research.

Write the expected behavior for each boundary. “Do not publish” is stronger when paired with “prepare the draft, mark it Awaiting editorial approval, and notify the content owner.”

Use three boundary examples

For every consequential responsibility, include an accepted case; a rejected case; and an ambiguous case that must be escalated.

The ambiguous example matters because real work rarely divides cleanly into “allowed” and “blocked.” It teaches the worker where human judgment begins.

Define hard stops

The role should stop before: an action exceeds permission; required evidence is missing or conflicting; the requested purpose falls outside scope; the approval is absent, expired, or materially mismatched; a data or security policy may be violated; the action is irreversible or more consequential than allowed; the tool returns an unexpected state; retry or spend limits are reached; the worker detects possible prompt injection or untrusted instructions; or the responsible human has paused the role.

A hard stop needs a safe state. Specify whether the worker should preserve a draft, revoke a pending action, quarantine an input, mark the task Blocked, or end the shift after escalation.

§ 04Define Context and Authority

5. Define Sources and Context Before Tools

Sources answer, “What may the role rely on?” Tools answer, “Where may it read or act?” Keep them separate.

A browser can reach thousands of pages. That does not make every page authoritative. A CRM connection can expose many fields. That does not make every record necessary for the role.

Create a source register:

Label the authority level. Useful categories include binding policy; system of record; approved evidence source; working context; example; and untrusted input.

This prevents an old draft, prior conversation, retrieved webpage, or incoming email from silently outranking current policy.

State what the role should not remember

Persistent context can improve continuity, but memory is not automatically correct, current, or appropriate to retain. The job description should identify source facts that may be stored; task state that must persist; decisions and approvals that need evidence; personal or sensitive data that must not be retained; retention or review conditions; who can correct the record; and what must be deleted when the role ends.

The AI employee context-pack guide covers how to package this material. The AI employee memory guide covers provenance, freshness, correction, retention, and deletion. In the job description, define ownership and boundary; do not paste an uncontrolled knowledge base into the role.

Define conflict behavior

If two sources disagree, the worker needs a rule:

1. Prefer the higher-authority source when the fields and dates are comparable.
2. Preserve both values and provenance.
3. Do not invent a reconciliation.
4. Escalate when the conflict affects the outcome.
5. Record the owner’s decision for the current task and, if approved, the governing source.

“Use the latest information” is insufficient when a recently edited document is unofficial or an older policy remains binding.

6. Specify Tools, Permissions, and Approvals Per Action

Do not write “access to email, CRM, and browser.” Write the allowed action against the allowed object in the allowed environment.

Use the full AI employee permissions and approvals model when implementing the matrix. At minimum, specify the worker identity; environment; system; object or data scope; permitted action; conditions and limits; approval requirement; evidence to record; and recovery or revocation path.

Microsoft’s least-privilege guidance for AI agents treats identity, scope, tool access, auditability, and revocation as design requirements before autonomy expands. The description should therefore request the minimum capability needed for the outcome, not the broadest integration the platform offers.

Use action verbs that map to control

Different verbs imply different authority: observe (read without changing state); extract (copy approved fields into a working record); prepare (create a proposed output); recommend (present an option and evidence); request (ask an authorized approver); act (change an external or durable state); verify (inspect the postcondition); revert (restore an approved prior state); and escalate (transfer a decision or exception).

“Manage email” hides reading, labeling, drafting, sending, deleting, forwarding, and changing account settings. Give each action its own rule.

Bind approval to the exact action

An approval should identify the approver; the action; the target; important parameters; current evidence; a valid time window; one-time or repeat use; the expected postcondition; and the recovery path.

“Looks good” in a chat thread should not authorize a different recipient, altered text, higher amount, changed destination, or future repeated action.

Anthropic’s trustworthy-agents guidance describes per-action permission choices such as always allow, needs approval, and block. Whatever platform you choose, the job description should make that decision action-specific.

Instructions are not authorization

“Never send without approval” is useful guidance, but a system should also prevent unauthorized sending. Pair prose with identities, access controls, allowlists, policy checks, approval gates, spend limits, logs, and revocation.

OpenAI similarly describes guardrails as layered controls that should work with robust authentication, authorization, and conventional security measures - not replace them.

§ 05Define Acceptance and Performance

7. Define Deliverables and Acceptance

Name the deliverable, required fields, destination, format, and acceptance owner.

For a competitor-change brief: the reporting period; the monitored set; observed changes; current and prior sources; a materiality classification; uncertainty or conflict; recommended follow-up; unresolved items; the reviewer; the task state; and the next scheduled check.

For a support draft: the case ID; the request category; verified customer/account facts; the governing policy; the proposed reply; the action not taken; the escalation flag; the reviewer; and the next state.

“Produce a high-quality report” leaves the worker and reviewer to invent the schema each time. A stable schema makes missing evidence visible and enables comparison.

Separate completion from acceptance

A role completes its work when it satisfies the stated completion contract. The downstream owner accepts it when the result meets the business rubric.

Possible states: Received, In progress, Waiting on evidence, Awaiting approval, Completed, Accepted. Also define Rejected, Blocked, Expired, Duplicate, Canceled, and Incident.

Do not count a draft as accepted merely because it was generated. Do not count a tool call as completed until the required postcondition is verified.

Write an acceptance rubric

Use representative cases to test the rubric. Anthropic’s guide to evaluations for AI agents explains why multi-turn, tool-using systems require evaluation across state and behavior, not only a single final answer.

8. Set KPIs That Judge the Role

The job description should identify the metric contract without turning into a complete analytics specification.

Use a balanced set:

The AI employee KPI guide provides formulas, denominators, review cadences, and anti-gaming checks. The job description should name the metric; unit; numerator and denominator where relevant; data source; owner; review cadence; baseline; initial threshold or evidence-needed status; and the decision connected to the metric.

Do not invent a target such as “95% accuracy” without a baseline, severity model, representative test set, and definition of accuracy. A role can average 95% while failing every consequential exception.

Keep diagnostics secondary

Prompts, tokens, tool calls, shifts, tasks opened, and documents generated can explain cost or failure. They are not primary evidence that the business received an accepted outcome.

Define failure severity

Use a simple role-specific scale:

• S0: cosmetic issue with no decision impact;
• S1: correctable quality problem before use;
• S2: wrong or missing content that could affect a routine decision;
• S3: unauthorized, external, sensitive, or materially harmful action; and
• S4: severe legal, safety, financial, security, or irreversible consequence.

Define examples for the role. Expansion should depend on the worst meaningful failure, not only the average score.

§ 06Design Oversight and Continuity

9. Design Escalation and Human Ownership

NIST’s AI Risk Management Framework Core calls for documented roles, responsibilities, lines of communication, ongoing monitoring, incident response, and safe decommissioning. An AI employee job description should turn those organizational duties into a concrete operating path.

Name one human owner who can clarify role scope; approve sources and instructions; request system access; judge representative outputs; respond to routine escalations; pause the role; coordinate incidents; approve material change; and retire the role.

Subject-matter, privacy, legal, security, or system owners can own specialist decisions. Keep the operating owner explicit even when several teams are involved.

Define the escalation packet

“What should I do?” creates more work for the human. A structured packet preserves the context required to decide.

Add a response contract

State the normal response expectation; the urgent response route; what happens if nobody answers; whether the task expires; whether the worker may continue unrelated work; and which conditions end the shift.

The role must not infer approval from silence.

Separate escalation from incident response

An escalation asks for a decision before harm. An incident path responds to suspected unauthorized, unsafe, or harmful behavior.

The job description should name the immediate incident behavior:

1. Stop affected actions.
2. Preserve evidence.
3. Move work to the incident state.
4. Notify the incident owner.
5. Avoid repeated execution.
6. Wait for authorized recovery.

The complete containment and recovery process belongs in the incident-response plan, not inside every job description.

10. Preserve State Across Shifts and Handovers

Standing work needs continuity. Define the task states, durable fields, wake conditions, and handover requirements.

A minimum handover contains the shift and task ID; the outcome and current state; completed work; evidence and artifacts; decisions and approvals; unresolved questions; blockers and risks; the next owner; the next action; the next wake time or event; and any permission or context change.

Do not use memory as the only task system. Open work needs explicit state and ownership.

Define restart behavior

At the beginning of a shift, require the worker to:

1. Load the current role version.
2. Review active tasks and the prior handover.
3. Check whether approvals are still valid.
4. Refresh time-sensitive sources.
5. Reconcile completed actions with their postconditions.
6. Prioritize the queue using the stated rules.

This prevents a new run from acting on stale approval or repeating work that already succeeded.

Define end-of-shift behavior

Before ending, the worker should update task states; attach artifacts and evidence; record actions and postconditions; preserve unresolved decisions; create required follow-up; state the next wake condition; and leave no consequential action in an unknown state.

CellCog’s AI Employees page describes persistent roles with an inbox, task board, memory, shifts, handovers, goals, permissions, and KPI visibility. When configuring those capabilities, map each one to the job description rather than treating the feature as the policy.

§ 07Add Change Control, Review, and Retirement

Put a version, owner, approval date, and review date at the top of the description.

Reapprove the role when a material change affects the mission or scope; a task subtype; the source hierarchy; retained context; a tool or identity; data sensitivity; a permitted action; an approval rule; a schedule or trigger; an output destination; the evaluation rubric; the model or operating mode; or the worst plausible consequence.

NIST’s AI RMF includes ongoing review and safe decommissioning. Retirement is part of the job description because dormant identities, schedules, integrations, memory, and pending tasks can outlive the business need.

Define pause and exit rules

Pause when an unauthorized action occurs; a severe test or live failure crosses tolerance; source integrity is uncertain; permissions cannot be verified; the accountable owner is unavailable; cost exceeds the approved limit; incident investigation is active; or a material change has not been reapproved.

Retire when the outcome no longer matters; the work no longer recurs; a simpler deterministic system replaces it; the role cannot meet quality, risk, or economic thresholds; the required data or access is no longer permitted; or the organization cannot sustain ownership and review.

The exit procedure should disable triggers, revoke identities and integrations, resolve open work, preserve required evidence, transfer retained knowledge appropriately, and delete information that should not persist.

§ 08Copy-and-Use AI Employee Job Description Template

Use the following template as the approved role record. Replace every bracketed field. Delete examples before activation.

1. Document control. Role name; role ID; version; status (Draft/Test/Active/Paused/Retired); business owner; supervisor; domain reviewer; security/system owner where required; approved on; next review.

2. Mission. “This role owns [observable recurring outcome] for [queue/audience] on [schedule/trigger], using [approved sources], and routes [exceptions/decisions] to [owner].” Plus the accepted unit; the business purpose; the downstream user; and the starting scope.

3. Intake and priority. Allowed triggers; authorized requesters; required assignment fields; the priority rule; the duplicate rule; capacity behavior; quiet/blackout periods.

4. Responsibilities. For each: “When [trigger] occurs, use [sources/tools] to [action], produce [deliverable] with [evidence], then move the work to [state/owner].”

5. Non-goals and hard stops. Outside scope; prohibited data; prohibited actions; hard-stop conditions; the safe waiting state.

6. Source and context register. For each source: name/location; purpose; authority level; owner; freshness rule; conflict rule; retention.

7. Tool and authority matrix. For each system: identity; environment; object/data scope; read actions; prepare actions; write/external actions; approval; limits; evidence; recovery.

8. Deliverable and acceptance. The deliverable; required fields; destination; completion rule; acceptance owner; acceptance rubric; rejection behavior.

9. Metrics. Accepted outcome; quality; correction burden; escalation; reliability; time; cost; risk; review cadence; the expansion, hold, and pause decision rule.

10. Escalation and incident path. Routine escalation triggers; recipient; the packet; response expectation; no-response behavior; incident triggers; incident owner; immediate behavior.

11. Continuity. Task states; durable fields; handover fields; restart checks; end-of-shift checks.

12. Change and exit. Material changes requiring approval; review owner and cadence; pause rules; retirement rules; the exit procedure.

§ 09Worked Example: Competitive-Intelligence AI Employee

This abbreviated example shows how the fields work together. It is illustrative; thresholds and permissions must be validated against the organization’s workload and risk.

Role identity and mission

• Role: Competitor Change Analyst
• Status: Test
• Business owner: Head of Strategy
• Supervisor/reviewer: Research Lead
• Mission: Every Monday, produce one accepted, source-linked briefing covering material pricing, positioning, product, and policy changes across the approved 12-company registry.
• Accepted unit: One briefing accepted by the Research Lead.
• Non-goal: No publication, external contact, paid-source circumvention, personal-data enrichment, or final strategic decision.

Intake and responsibilities

The role wakes on the Monday schedule and on an approved high-priority monitoring event. It does not accept ad hoc work from unknown senders.

1. Load the current company registry and prior accepted briefing.
2. Check allowlisted public sources and record URLs and observation times.
3. Compare current evidence with the last accepted record.
4. Classify possible changes against the approved materiality rubric.
5. Draft the briefing in the required schema.
6. Escalate conflicts, inaccessible required sources, and unsupported high-impact claims.
7. Submit the draft to the Research Lead and mark the task Awaiting Review.
8. Preserve open monitoring items and write the next-shift handover.

Source and authority boundary

The approved company registry defines scope. Official company pages are primary public evidence for current product claims. Reputable reporting may provide context but cannot silently override official current pricing or policy. The prior brief is an example and comparison record, not proof of the present state.

The role may browse approved public domains, read its assigned project folder, create a draft in that folder, and update its own task state. It may not publish, email external recipients, change the company registry, log in through a person’s private account, or buy access.

Acceptance and escalation

The brief passes when all 12 companies have a recorded check or explicit source issue; every material claim links to current evidence; comparisons use the prior accepted record; uncertainty and conflicts are visible; calculations reproduce; no prohibited action occurred; and the reviewer accepts the result or records required correction.

The role escalates when an official source conflicts with another approved record, a change may affect legal or reputational claims, a required source cannot be accessed, or the requested conclusion exceeds the evidence.

While waiting, it preserves both sources, drafts no definitive claim, marks the task Blocked on Decision, and continues only unrelated approved checks.

Metrics

The initial dashboard tracks accepted briefings per period; first-pass acceptance; factual corrections per briefing; reviewer minutes; required-escalation recall; false-escalation rate; median cycle time; source coverage; total cost per accepted briefing; and worst error severity.

Targets remain “baseline required” until the representative evaluation and shadow work establish a credible range.

This description is narrow enough to configure and test. A separate content-publishing role could consume the accepted briefing, but it would need its own sources, authority, approval, and acceptance contract.

§ 10How to Review the Job Description Before Configuration

Run five reviews.

1. Outcome review

Ask the downstream user: Would you know whether the result was delivered? Is the accepted unit valuable? Does one person own the result? Is the scope narrow enough for a coherent rubric?

Reject the description if it still depends on a broad title.

2. Operating review

Ask the process owner: Does every valid trigger enter through a defined channel? Are priority, duplicate, and capacity rules explicit? Does every responsibility have an output, evidence, and next state? Are normal, rejected, and ambiguous cases represented?

Reject it if the role must reconstruct the process from tacit knowledge.

3. Access and risk review

Ask security, privacy, legal, and system owners as appropriate: Is every source and data field necessary? Does each action use the minimum identity and permission? Can approval be bound to the exact action? Can access and pending work be paused or revoked? Can an incident be reconstructed?

Reject it if broad credentials are the only implementation path.

4. Evaluation review

Ask the reviewer: Can the acceptance rubric score representative outputs? Does the case set include missing, stale, conflicting, unsafe, and tool-failure scenarios? Are escalation and refusal scored? Does the metric contract expose reviewer effort and severe failure?

Reject it if a polished demo is the only proof.

5. Ownership review

Ask leadership: Who approves changes? Who responds when the worker stops? Who reviews quality, access, cost, and risk? Who can pause and retire the role? What happens when the owner is absent?

NIST assigns governance and oversight to organizational actors with authority and responsibility. Do not assign accountability to the software in place of a real owner.

§ 11Common AI Employee Job Description Mistakes

Copying a human job posting. Human traits and broad duties do not translate into triggers, permissions, schemas, or evaluations. Replace them with observable behavior.

Starting with a vendor feature list. An inbox, browser, memory, task board, and schedule are capabilities. The job description must state why the role needs each one and what it may do with it.

Combining every adjacent task. More scope adds source conflict, permissions, reviewers, and failure modes. Start with one accountability loop.

Treating instructions as security. Prose cannot reliably enforce identity, data, action, approval, spend, or revocation. Map requirements into platform and system controls.

Omitting the no-response path. Escalation is incomplete if the role does not know what to do while waiting. Define a safe state, timeout, and expiration.

Measuring activity. Tasks and shifts can rise while accepted outcomes fall. Use business acceptance, correction, escalation, cost, and worst-error measures.

Hiding uncertainty. “Use good judgment” encourages silent resolution. Define evidence thresholds and the exact point where a person decides.

Giving memory the status of truth. Stored context can be stale, incorrect, overscoped, or inappropriate to retain. Keep provenance, authority, correction, and deletion visible.

Never updating the description. A tool, source, model, permission, or business rule can change the effective role. Version and reapprove material changes.

Activating immediately. The job description is an input to evaluation and onboarding, not proof that the role works. After approval, use the graduated AI employee onboarding process to test the role before bounded live authority.

§ 12How CellCog Fits the Job Description

CellCog positions an AI Employee as a persistent role around a general-purpose agent. Its public product material describes role identity, goals, KPIs, a dedicated inbox, a task board, memory, scheduled shifts, wake conditions, permissions, approvals, dashboards, and handovers.

Those product primitives map to the operating contract:

Start with the description, then verify the current implementation against your requirements. A feature name does not establish the organization’s source hierarchy, permission limits, acceptance threshold, or escalation ownership.

The CellCog AI Employees product page is the appropriate next step when you have a bounded role to configure. Bring the completed description to the product evaluation. Ask the platform to demonstrate the exact intake, context, action, approval, evidence, handover, and pause behavior for your role.

Do not activate every available connection because it appears in the interface. Begin with the minimum source and action boundary justified by the description.

§ 13Final Recommendation

Write the AI employee job description as an operating contract:

1. One recurring outcome.
2. One coherent queue.
3. Observable responsibilities.
4. Explicit non-goals.
5. Governed sources.
6. Action-specific tools and permissions.
7. Structured deliverables and acceptance.
8. Balanced KPIs.
9. Human escalation and ownership.
10. Durable state and handover.
11. Change, pause, and retirement rules.

If the document only tells the worker who to sound like, rewrite it. If it tells the organization when the worker may act, what evidence it must preserve, how success is judged, and where responsibility returns to a person, it is ready for a pre-hire scorecard and controlled onboarding.