BlogsOct 4, 2026
Beyond the Bot: a guide to operating work on Grok Bot and OpenAI Dots
From a job description for an AI agent to a long-running, versioned work system.
By Walid Negm
Agents such as Grok Bot and OpenAI Dots can now sign in to your tools and finish work across many steps. That opens up a lot: work that waited for someone’s time can start, and people can spend their day on the parts only they can do.
A bot is an actor. A work system is the structure that says how the work gets done, what each actor may do, what it relies on, and how the whole changes over time.
For one person running one routine on a fixed fee, the bot’s description, routines and tool access are often a great way to get started and be productive. This guide is for the work that goes beyond that:
- more than one agent, or agents working alongside people;
- anything official that cannot be undone;
- long-running or costly work;
- work that changes and needs versions;
- work where accountability is not delegated to the AI system, but shared by you or the business.
AI is clearly taking on more of the work, and the systems behind these agents, such as Grok, ChatGPT and Claude, are becoming more capable: they run the agent loop, the reasoning and the tools. Whether the agents are effective, and stay on course, still comes down to the details. And while AI may own a lot more of the work, it is also true that accountability and responsibility still rest with you.
When consequences matter, how clearly the work is described, who does which part, and what each agent is allowed to do need to be more controlled and transparent.
Describing an agent starts with a job description, but does not end there
Ask a team to describe the agent they want and you will hear a name (“the Proposal Agent”), a short title (“sales assistant”) or a list of what it does. Each is a different description of the same thing, and none of them is enough to run it.
We are no longer writing a person’s job description. A person fills the gaps in a job description with judgment, context and a conversation with their manager. An agent fills them with guesses. An agent’s job description can follow a similar format, but it needs far more specificity: what it is for, what finished means, what it must never do, what to do when it is unsure.
A good way to write that description is the one software teams use to scope a feature: an epic that says what the agent is for, broken into user stories, each one thing it must do. That is how you write a well-defined prompt, not how the model works: the model never sees the stories, only the prompt they become. The same description then carries the work from spec, to prompt, to the platform that runs it, and is versioned as the work changes. A spec is not a check, though. Finished examples, the failures it must catch, and a rule for when to stop are what show that the agent does the job.
What a bot carries, and what consequential work adds around it
The Grok Bot marketplace already lists bots for most teams. A good listing carries the job, what the bot must never do, what done means, the facts it needs, the playbooks it runs and the apps it can use. Both Grok Bot and OpenAI Dots pause consequential acts for approval and let you set rules for what an agent may do on its own; Claude Managed Agents does the same for developers, and keeps each agent’s setup as numbered versions.
- ✓AI systems such as Grok, ChatGPT and Claude are rapidly solving the agent itself: intelligence, memory, tools, a computer, schedules, permissions and, increasingly, the ability to hand work to other agents.
- ✗What they do not yet give you is your organization’s operating logic around that work, written down, versioned and owned by you: your beliefs and values, who does what, how people and agents work together, who hands work to whom, and what authority each participant has in this specific piece of work. Each gap below is linked to the step in this guide that addresses it.
Work design
- ✓The agent's job or goal, and what it must never do
- ✓Scheduled and recurring work you can pause
- ✗The work itself, saved and versioned: the route, and the agents and people organized around one outcome Step 1
- ✗Alternative designs of the same work, side by side Step 1
- ✗A model of each design before it runs: does it meet its targets and improve on today, where will it queue, and what will it cost Step 3
Authority
- ✓Consequential acts, such as sending, buying and deleting, pause for your approval
- ✓Rules for what an agent may do alone, what needs your yes, and what it hands back
- ✓A record of each call it was allowed, asked about or denied (Claude Managed Agents)
- ✓An automatic check of risky actions against your rules before they run (OpenAI Dots)
- ✗One plain view of what every agent and person may do across the work, before it starts Step 5
- ✗Authority tied to the piece of work and its version, not only to one agent's settings Step 5
Facts & Grounding
- ✓Memory of your business and preferences, including from the apps you connect
- ✓Your answers from setup, saved for next time
- ✗Rules for which sources to trust, how fresh they must be, and what to do when they disagree Step 6
- ✗For each agent, which source is the truth for which decision, and what its memory may be trusted for Step 6
- ✗Each source named where it lives, so the work points to it instead of copying it Step 6
Coordination
- ✓Connections to the apps you already use
- ✓Agents that hand work to other agents, in products that run more than one
- ✗The arrangement each group works in, and who decides what happens next: a lead, the next owner, the group or a fixed rule Step 2
- ✗One written, versioned description of who does what and who hands to whom, people included Step 2
- ✗One package for the whole work that you own: its description can move, its credentials cannot Step 8
A guide for consequential work with AI agents
Each step grows with the consequences of the work. None of it is needed before a simple bot can run.
1. Describe and design the work
Before choosing an agent, describe how the work actually runs today, and say what it must achieve. An agent cannot follow a route nobody has written down, and a design cannot be judged without the targets it has to meet.
| What | Why | Example |
|---|---|---|
| Write down the process as it runs | An agent needs the route: the tasks, their order, the decisions between them and where the work ends. | How an insurance claim is reviewed, from the first notice to the payout decision. |
| Say who does each task | A task with no owner is a task nobody does. With people and agents side by side, the owner has to be explicit. | Intake is done by an agent; approving the payout stays with a claims adjuster. |
| Name the systems each task touches | Access follows the work. You cannot limit what you have not listed. | The triage agent reads the ticketing system and writes to the on-call schedule. |
| Set the targets first | The value the work must deliver: the outcome, how fast, how well and at what cost. A design is judged against them, and so are its agents. | Claims paid within five days, with fewer than two in a hundred reopened. |
| Consider more than one design | The first arrangement is rarely the best. Sketch alternatives and compare them against the same targets before choosing one. | Claims review with a lead and specialists, against the same work handed from owner to owner. |
2. Organize the people and agents
The route says where the work goes; an arrangement says how a group shares it while it is there. Write down who decides what happens next: a lead, the next owner, the group, or a fixed rule. Then the routing is visible, not left inside the model.
| What | Why | Example |
|---|---|---|
| Choose how each group works together | There will be many ways to arrange work, not only a chain of agents passing work along. A lead with specialists, work that changes “hands”, a group that decides together and a shared board each say who decides and when the work is done. See the ways to arrange work. | The claim's assess stage: a lead adjuster with coverage, fraud and medical agents as specialists. |
| Say when a group's work is done | Without a finish line, a group of agents either keeps going or stops at a guess. | A product launch's claims are done when legal has approved every one. |
| Give agents built elsewhere their place in the work | An agent from another vendor or a marketplace arrives with its own description, which is its job. It does not know where it sits in yours: who hands to it, who it hands to, and what it may do here. | A lead-qualifying agent built in a CRM, placed in the sales route with its handoff to the account owner. |
| Find the task that holds everything back | Adding agents anywhere else does not make the whole faster. | In a supply shortage, waiting for supplier confirmation holds everything else back. |
3. Assess the change, and manage it
Before writing any agent's job, assess what the change means: whose work changes, what cannot be undone, and what the business would come to depend on. For a small change, the assessment takes minutes and decides how far into this guide you go. For an organization moving a large part of its work to AI, it is the business case. Going all in on AI changes people's jobs, the order in which teams move, and what the business depends on, and a simulation shows that before anything moves: who it reaches, by how much and when, where work will queue, and what it costs and saves.
| What | Why | Example |
|---|---|---|
| Assess what the change would mean | The consequences, not the number of agents, decide how much of this guide the work needs. | A drafting agent needs little; one that issues refunds, or changes forty people's jobs, needs much more. |
| Plan the change for the people it reaches | In a large business the hardest part is rarely the agents. It is the people whose work changes: new roles, new skills, new approvals, and the order in which teams move. | Telling the adjusters what their work becomes, and what they will learn, before the agents go live. |
| See where it queues | Agents speed up their own task and can flood the next one. | Faster intake sends a backlog to the two adjusters who approve payouts. |
4. Define each agent's job
An agent's job description is its spec, and examples are its check. Start with what finished looks like and the failures it must catch; the rest becomes the prompt and changes, version by version, with the work.
| What | Why | Example |
|---|---|---|
| Show finished examples and failure cases | A description says what you meant; examples show whether the agent does it. | Two approved proposals, and one with an unsourced claim the agent must reject. |
| Start with an epic | One paragraph on what the agent is for and what it delivers, before anyone writes a prompt. | A proposal agent drafts customer proposals from approved pricing and past wins. |
| Break it into user stories, then the prompt | Stories are small enough to check, and together they are the agent's spec. The model never sees them; it follows the prompt they become, which does not drift from the spec. Each story is something the agent must achieve or never do, not a step in order. The route and the arrangement set the order between agents; within its own part, the agent decides. | As the proposal agent, I draft the pricing section from the approved rate card: one line of its prompt. |
| Say what to do when unsure or stuck | Left alone, an agent resolves doubt on its own judgment, and an open-ended loop is an open-ended bill. Limit the retries and name who takes over. | Not sure a customer is eligible? Ask the account owner. After two failed attempts to reach a supplier, hand it to the buyer. |
| Set how much it does alone | Autonomy is a level that should rise with results, and can fall again. | A support-triage agent starts by asking before acting, and acts on its own once its results hold up. |
5. Set each agent's authority
An instruction is not a permission. A prompt says what an agent should do; its authority says what it may do. That belongs outside the prompt, where it can be read, checked and changed. In these products that means their approval rules; in your own systems, it means the access each system grants the agent's account, which a prompt cannot widen. Know which limits the product enforces: connected apps are often shared by every agent on the account, so telling one agent to stay in one folder is an instruction, not a limit.
| What | Why | Example |
|---|---|---|
| Say what it may act on, and what never | Write the actions it may take and what they may change, and what is never allowed. | The proposal agent may draft and share internally, and never send to the customer. |
| Say where, and within what limits | Authority holds in named systems and within limits: an amount, a group of customers, a time window. | Refunds up to $200, in the billing system, for customers in good standing. |
| Give consequential acts explicit authority | Whatever cannot be undone needs explicit authority: a person's approval, or a standing grant written in advance with its limits. Products such as Grok Bot and OpenAI Dots already pause these acts and let you set narrow rules. Neither ties a rule to a version of the work, so when the job changes the old rule stays in force until someone changes it. | Refunds under $200 go out under a standing grant; larger ones wait for a person. |
| Say when its authority changes or ends | Authority belongs to the version of the work it was written for, and should expire or be reviewed. | The grant ends with the quarter and is rewritten for version 3 of the work. |
| Check the agent before it starts | Ask it what it intends to do and compare the answer with what you allowed. | Asked about an open incident, the agent names every system it would touch. |
6. Ground its decisions
Grounding gives a decision its basis; authority decides whether the agent may act on it. An agent that knows which sources to trust, how current they must be and what to do when they disagree can reason before it acts, whether or not code checks its work afterwards.
| What | Why | Example |
|---|---|---|
| Name the sources it must trust | How fresh the information must be, and what to do when two sources disagree: ask, trust the live system, or stop. | Use the live inventory, re-checked just before acting; if it disagrees with the plan, ask. |
| Say what each source is the truth for, agent by agent | Access is not trust. An agent connected to the CRM, a shared drive and its own memory still has to know which one decides, and two agents on the same apps may rely on different things. Memory is a source too: these products now keep a lasting memory of you and your work. Say what it may be trusted for, such as how you like things done, and what it may not, such as prices or account status. | Account status from the CRM; discount bands from the approved pricing deck; your preferred tone from its memory, never a price. |
| Point to sources; do not copy them | A copy goes stale and spreads. Say where each source lives and what it is the truth for, and let the product connect to it where it is governed. | Finance drive, Pricing, Q3 deck: named, not attached to the agent. |
| Give it your organization's knowledge | Your documents and past decisions are what make its reasoning yours rather than generic. | Past claim decisions and the policy wording, for a claims agent to reason from. |
| Ask it to cite what it relied on | A recommendation that names its source can be checked; one that does not has to be trusted. | A new support model, proposed with the cases it was based on. |
7. Cost it when the work calls for it
Simple work on a fixed-fee product such as Grok Bot rarely needs costing. Once the work runs for a long time, needs more components, or uses compute and storage you pay for separately, the cost decides whether it is worth doing.
| What | Why | Example |
|---|---|---|
| Cost the agents | Model use, infrastructure, the people who review the work and the change itself all count. | A support agent fleet running all day, priced with the people who review its work. |
| Look at the cost per piece of work | The total hides whether each piece of work became cheaper. | The cost of one activated service, before and after agents. |
8. Package it, hand it over, and own the work
A work-system package brings everything above together: the work order, each agent's job description, what each agent may do, the sources it must trust and what finished means. The bot runs the work. The package is how you own it: if the work is described only inside one product, leaving means writing it again, and you cannot show what an agent was told. Owning it also leaves you free, if you choose, to run the same work on Grok Bot, OpenAI Dots or Claude Managed Agents, or to move one part to a system that does it better. Each agent gets the instructions it needs. Its authority stays separate, so it can be checked rather than trusted as text. You keep the whole.
| What | Why | Example |
|---|---|---|
| Give each agent only its part | Each agent should receive its own job description and its own permissions, not the whole team's. | Each support agent's brief, pasted into its own Grok Bot. |
| Send the work order with it | The agents need the order of the work and who hands to whom. | The incident agents receive the steps and their handoffs, not a transcript. |
| Keep the package yours | If the work is described only inside one platform, leaving means writing it again, and you cannot show what the agent was told. Credentials, browser sessions and connected apps do not travel; the description of the work can. What moves is the description: each system's prompt is rewritten from it and checked against the same finished examples. | When an agent's result is questioned, you can show the brief it was given for that version of the work. |
| If you choose, put a part where it is done best | Optional, and not why you keep the package. AI systems are not equally good at everything. One may reason better about your domain; another may be better at images or 3D modeling. | Claims triage on one system; damage assessment from photos on another. |
| Own the handoffs between systems | When one part of the work depends on one AI system and the next runs on another, the handoff needs an owner, a format, and a fallback if a system is unavailable. | If the photo-assessment system is down, the claim goes to an adjuster rather than waiting. |
9. Keep track
| What | Why | Example |
|---|---|---|
| Keep an inventory | You cannot manage agents you cannot list, or the work they do. | Claims review, incident response and the launch, in one list. |
| Version the work | When the work changes, the agents' jobs change with it. | Version 2 of the launch adds a legal review. |
| Version the permissions | A permission belongs to the version of the work it was written for. | Revision 3 of the proposal agent's permissions, written for version 2. |
| Version the prompts | When a result changes, you need to know which prompt produced it. | The triage agent's prompt as it was at each release. |
| Re-check it when anything changes | Finished examples are a one-time check. Run them again, with the rules for when it is unsure or must stop, whenever the prompt, the model or the work changes, and when results start to drift. | The proposal agent's failure cases, run again after each new prompt version. |