The short version
Grok Bot answers "what if the agent were a new teammate": each Bot gets its own computer, signs in to your tools the way a human would, and works 24/7, GUIs included. Dittwo answers "what if every employee you already have got an agent": one per person, scoped to what that person can already reach, in a sandbox that never holds a credential. The difference is what is sitting on the box at 3am. A Bot's computer holds live logged-in sessions to your tools. Ours holds placeholders. If the work lives in GUI-only apps and you want a headcount you can message, try Grok Bot. If an agent's access has to map to an employee and survive a security review, that is us.
Credit where it is due. Grok Bot's computer-use is real: it drives websites and desktop apps that have no API, learns a workflow by watching you do it once, and runs it on a schedule afterwards. None of that is in Dittwo, and for back-office work trapped in GUI-only tools it is the difference between automating the task and not. This page is about a different question: whose identity the agent carries, and where its credentials live.
vs
Grok Bot A new teammate versus an extension of one you have
Grok Bot's unit is the Bot: a new identity with its own computer, its own memory, and whatever access someone signed it into. The product page says it plainly: "sign in to Zendesk so I can work the support queue." That works, and it creates a login that belongs to no employee. When the person who set it up leaves, the Bot keeps working with the sessions it holds. When security asks who can reach the billing system, the honest answer now includes several teammates who do not appear in the org chart.
Dittwo's unit is the employee. Each person's agent reaches exactly what that person already has, through a gateway that injects credentials at the network boundary, per request. There is no new identity to provision, audit, or forget about. Revoke the person and their agent stops resolving credentials on the next request.
The box that never sleeps
"Bots have their own computer" is the feature, and it is also the exposure. For a Bot to use your tools like a human, that computer has to hold what a human's does: authenticated browser sessions, cookies, and whatever passwords were typed in during setup. It holds them around the clock, because working while your laptop is closed is the point. A prompt injection that lands on a machine like that has everything it needs already in hand. Dittwo's sandbox boots with placeholder credentials, model key included. The real secret is spliced in at the wire on the way out, so there is nothing on the box worth stealing at 3am or any other time, and every request passes a policy check that can allow, block, rate limit, or hold for a named human first.
The model
Built for
DittwoYour existing people: one agent per employee, each a scoped extension of its person
Grok BotNew digital headcount: Bots you hire, name, and assign a job to
Neither is wrong. They answer different questions about what an agent is.
Identity
Dittwo✓The employee's. The agent cannot reach anything its person could not reach directly
Grok Bot✕The Bot's own. Its access is whatever accounts it was signed into, unrelated to any employee's permissions
Every Bot is a new identity your access reviews have to know about.
GUI-only tools
Dittwo✕Not covered. Dittwo agents work through APIs, CLIs, and MCP servers
Grok Bot✓Covered well. Bots drive websites and desktop apps with a mouse and keyboard, and learn workflows by demonstration
Grok Bot wins this outright, and for some teams it decides the evaluation.
Credentials
What the agent holds
Dittwo✓Placeholders. Real keys injected at the network boundary per request, model key included
Grok Bot✕Live logged-in sessions, cookies, and typed-in passwords on the Bot's computer
A prompt injection can only exfiltrate what is present. On one side, nothing is.
Exposure window
Dittwo✓Per request. A credential exists on the wire for one call and nowhere else
Grok Bot✕Continuous. The Bot works 24/7, so its sessions are live around the clock
The always-on computer is the product's headline feature and its largest attack surface.
Offboarding
Dittwo✓Revoke the employee. Their agent stops resolving credentials on the next request
Grok Bot✕Find every account each Bot was signed into and rotate or close it
Logins that belong to no person are the ones audits miss.
Control
Where guardrails live
Dittwo✓At the network. Every request is evaluated, whatever produced it: MCP calls, CLI commands, curl, or code the agent just wrote
Grok Bot~In the loop: Bots come back when your approval is needed, decided by the Bot
A checkpoint the agent chooses to visit is different from one it cannot route around.
Per-request verdicts
Dittwo✓Allow, block, rate limit, or hold for a human, per request, by rule set once
Grok Bot✕The Bot asks when it judges a step needs sign-off
Rules set in advance beat judgment calls made by the thing being governed.
Audit trail
Dittwo✓One log across every agent: who asked, what was called, what was injected, what was denied, tied to an employee
Grok Bot~Activity per Bot in the app, tied to a Bot
Compliance stories are written in terms of people. Mapping Bots back to people is your job.
Deployment
Dittwo✓Dittwo Cloud, or the whole system on your own infrastructure on the Enterprise plan
Grok Bot✕Hosted only, closed source, on xAI's infrastructure
If self-hosting or reading the source is a requirement, the comparison ends here.
Models
Dittwo✓Model-agnostic across 25+ providers, or bring your own keys
Grok Bot✕Grok, on xAI's service
Reasonable from a model company, and still a single-vendor dependency.
Day to day
Where you talk to it
Dittwo~Web, terminal, and Slack
Grok Bot✓Desktop and iOS apps built around messaging your Bots, plus multi-Bot threads
The teammate framing is well executed, and the mobile apps are ahead of us.
Learning workflows
Dittwo~Skills and MCP servers, written once and inherited by every employee's agent
Grok Bot✓Watch-and-learn: do a workflow once in front of the Bot and it becomes a scheduled routine
Demonstration beats documentation for non-technical users.
Price
DittwoFree for three people, then paid per user and agent; self-hosted deployment on the Enterprise plan
Grok Bot$200/month per Bot on Cursor Ultra, $120/seat/month on Premium Teams
A Bot is priced like headcount because that is what it is.
When to use which
Use Grok Bot when
- The work is trapped in GUI-only tools with no API, and computer-use is the only way in
- You want to teach by demonstration: do it once, let the Bot repeat it on a schedule
- The teammate model fits: a named Bot with a job, messaged from desktop or your phone
- You are all-in on Grok and want the deepest first-party agent xAI ships
Use Dittwo when
- An agent must never reach something its human could not reach directly
- Credentials must not sit on an always-on machine, live sessions included
- Someone has to answer which agent did what, in one log, tied to employees
- Some actions must be blocked or held for a human by rule, not by the agent's judgment
- You want to choose the model, or change it later, without changing platforms
- Self-hosting or reading the source is a requirement rather than a preference
Common questions
Isn't a Bot with its own computer just an employee with a laptop? We trust those.
An employee's laptop is tied to a person: their permissions, their accountability, their offboarding. A Bot's computer holds real sessions with none of that attached. It is the access of an employee without the identity of one, which is exactly the combination access reviews exist to catch.
What does Grok Bot do better?
Computer-use, teach-by-demonstration, and the teammate experience. It drives GUI-only apps we cannot touch, turns a workflow you performed once into a scheduled routine, and its desktop and mobile apps make managing several agents feel natural. If your bottleneck is GUI work, it may simply be the right tool.
Can Dittwo agents work around the clock too?
Yes. Agents run server-side in their sandboxes, not on your laptop, so a closed lid changes nothing. The difference is what is in the box while it runs: our sandbox holds placeholder credentials, so the always-on window exposes nothing.
Grok Bot asks for approval before sensitive steps. Isn't that the same as your holds?
The Bot decides when to ask. Dittwo's gateway decides, by rules set in advance, and the agent cannot route around it because every request leaves through the wire where policy runs. A checkpoint is only a control if the thing being checked cannot skip it.
Could we run both?
Yes, split by surface. GUI-only workflows with no API are Grok Bot's territory. Work that touches company APIs, credentials, or anything an auditor will ask about fits the per-employee model. Any agent that speaks HTTPS, Grok Bot included, can also be pointed at the Dittwo gateway to get per-request credential injection and the audit log.
Is the Bot identity model actually a problem?
It is a trade, and for a small team it may be a fine one. It becomes a problem at the point someone has to certify who can access what: every Bot is an identity that is not in the HR system, holding sessions nobody rotates, doing work nobody maps to a person. Companies spent a decade cleaning up exactly this pattern under the name 'service accounts'.
The longer version of the enforcement argument is in why an MCP gateway cannot see most of what your agent does, the closest architectural cousin is Dittwo vs Claude Tag, and the shape of the product is on the product page.