← All posts

AI agents & leadership

OpenAI Dots and Grok Bot: agents with a computer in the cloud

What OpenAI Dots and Grok Bot are, how their cloud computers work, and what Norwegian leaders should know before connecting company systems.

Conceptual illustration of OpenAI Dots and Grok Bot with separate cloud computers showing a browser, files and a terminal. Not product screenshots.

OpenAI Dots and Grok Bot give AI agents a computer in the cloud: a working environment with a browser, files and software that the agent can use to carry out tasks. You communicate through an app, while the work can happen on that remote computer and continue after you close your own laptop.

That setup is the starting point for understanding these products. For a Norwegian business leader, it raises a concrete question: what should this additional computer, and the agent operating it, be allowed to access in the company?

What does a computer in the cloud mean?

Think of a remotely hosted workspace supplied as part of the service. It has a browser that can open websites, storage for working files and tools for running software. It can keep working state between tasks. The cloud computer is the environment where actions happen; the AI agent interprets your request and decides which steps to take within its instructions and permissions.

There are three parts to keep distinct:

  • The agent: the software you give an assignment to, including the context and instructions it uses.
  • The cloud computer: the remote working environment where it can use a browser, handle files and run tools.
  • The connections: the accounts, apps and permissions that make particular company information and actions available.

A cloud computer does not arrive with access to your business. A mailbox, document store or customer system still needs an authorized connection or sign-in. The details differ between Dots and Grok Bot, including how their computers and accounts are shared.

OpenAI Dots: a personal agent with its own cloud computer

Dots is OpenAI’s persistent personal-agent product in ChatGPT. A dot combines ongoing conversation, relevant memory and a computer it can use for work. “Persistent” means that you can return to the same agent and continue an assignment with retained context, instead of explaining everything again.

In the setup described by OpenAI, you create your dot in ChatGPT, give it a name and optionally connect supported apps. The dot already has its own cloud computer. Connecting your personal computer is a separate, optional step.

OpenAI’s computer documentation describes its own files, software and browser sessions. You can inspect the remote computer and take control when needed, for example to sign in. Being logged into a website on your laptop does not automatically log the dot into it. Its cloud browser has a separate session.

This explains how you can send a request from your phone while your laptop is off. Cloud work uses the remote environment. If an assignment needs files or tools on your connected local machine, that machine must be online with the ChatGPT app open. The dot’s selected memories provide context, but they are not a complete or necessarily current business record.

Grok Bot: several agents working on a shared cloud computer

Grok Bot is a persistent-agent product in which you can create bots with different roles. It includes a remote working environment and tools for carrying out tasks. This is a broader product than the Grok chatbot people may know from X.

During Grok Bot’s onboarding, computer setup runs in the background. You create a bot with a name, a primary job and instructions.

The cloud computer belongs to your account and is shared by your bots. Each bot has its own screen, while files, browser sessions and command-line credentials are shared. Giving bots separate names does not isolate their access.

You can inspect this environment through Agent Computer and take over for a sign-in or other step requiring you. Cloud work can continue when your laptop is closed. Access to your local computer is a separate capability.

What can they do once the environment is connected?

The combination of an agent, a computer and authorized connections lets a request become a sequence of actions. An agent can find information, work with a document and prepare a result in the relevant tool. The useful scope depends on the apps, data and actions actually available to it.

For Dots, the tasks and memory documentation describes delegation to Work and Codex, background agents and recurring work. A dot could help investigate a customer issue, prepare an explanation and delegate a software change for review. Cloud coding requires a configured Codex environment. OpenAI describes proactive research as read-only; sending a message or changing a record needs the relevant authorization.

Grok Bot’s skills and routines distinguish a reusable method from when it runs. A reviewed method for preparing a weekly customer summary could become a scheduled routine. Learning from a demonstrated workflow produces a draft skill that still needs review and testing.

Its documented examples include reconciling expenses, researching customer accounts and reproducing software bugs. These show the intended range of work. They do not establish the success rate or economic return for a Norwegian company using different software, data and language.

Why this could change how a small team works

Automation and delegated software tasks already exist. What I find significant here is the combination of continuity, tools and a conversational way to assign work. A leader can describe an outcome, discuss an exception and let the agent continue, instead of reconstructing the whole task each time.

That could lower the effort needed to coordinate several ordinary steps: finding the relevant documents, checking what changed, preparing a response and returning with the one unresolved decision. For a Norwegian company with a small administration, the valuable output may be a proposal ready for review or a discrepancy explained before it delays delivery.

The same arrangement can also create more supervision. An agent may choose an outdated file, misunderstand a Norwegian contractual term or produce a plausible explanation that the sources do not support. If a manager must reconstruct every step, the apparent time saving disappears. The case for adoption rests on useful work completed after review and correction.

A Norwegian service company preparing a customer offer

Consider a hypothetical technical-services company. Its operations manager is visiting a customer when another customer requests a revised offer. The business has approved templates, a current price list and a shared record of delivery capacity.

Within a tested setup, an agent could gather the relevant documents, compare the changed requirements and prepare a revised draft with prices in NOK. It could flag that the requested delivery date conflicts with the capacity record and ask the manager to resolve that issue.

The manager reviews the commercial terms and decides what the company can promise. Sending the offer remains a separate, controlled action. The intended gain is that the manager returns to a prepared decision with its sources, rather than a collection of messages to investigate.

This is an illustrative workflow to test, not a documented customer result or a guarantee that either product can operate every company’s systems.

What Norwegian companies can actually access

Availability checked on 11 October 2026: OpenAI’s Dots documentation excludes the EEA from its personal Pro rollout. Business Premium and Enterprise have separate worldwide rollouts, introduced gradually, with Enterprise requiring administrator enablement. A Norwegian personal subscription and a company workspace therefore have different access conditions. Eligibility does not mean immediate availability.

For Grok Bot, access depends on an eligible Cursor plan or a supported SuperGrok plan linked to Cursor, along with supported account and data settings. Its documentation requires cloud storage and says the legacy Privacy Mode is incompatible. Check whether the available configuration meets the company’s requirements before connecting business data.

Grok Bot also has an @bot feature for starting a task from an X post. That feature excludes accounts based in Norway. This is a restriction on the X entry point, not evidence that all Grok Bot access is unavailable in Norway.

Data handling needs its own review. OpenAI’s enterprise cloud and local access guidance states that Dots does not support data residency or inference residency during the enterprise beta. It also distinguishes these products from strict zero data retention API configurations. Connecting a local computer does not mean all processing stays on that computer.

These are material product conditions to assess against your actual workflow and contracts. For the Norwegian legal and governance questions, see what Norwegian companies can allow AI agents to do. Avoid treating either a vendor’s global availability statement or a privacy setting as a complete assessment of your use case.

Give the agent a responsibility with boundaries

I would start with a responsibility whose output is easy for a named employee to check. Preparing an offer from approved materials is a clearer assignment than a broad instruction to manage customer relationships. A useful delegation brief specifies the result, permitted sources, allowed changes, required approvals and when to stop.

For the hypothetical company, that brief might read: “Prepare a revised offer using the approved template and current price list. Show the source of each price and flag conflicts with the capacity record. Save a draft in the review folder. Ask the operations manager to resolve missing terms. Do not send the offer, change customer records or promise a delivery date.”

Those instructions need technical support. OpenAI’s action controls distinguish drafting from sending and warn that custom rules can be followed imperfectly. Grok Bot’s security guidance likewise treats model-based review as one layer alongside limited access. Use account permissions and approval controls to restrict the actions that would be costly to get wrong.

Test what happens when a source is missing, a customer message contains instructions for the agent, or two documents disagree. A customer email is input to evaluate; it cannot grant the agent new authority. Also establish how to stop the work. OpenAI documents separate controls for the main conversation, delegated work and schedules, so stopping one task should not be assumed to cancel every related activity.

The opportunity is worth testing, and the result must be measurable

Management should compare elapsed time, human review time and corrected errors for a defined workflow. Include Norwegian-language quality, failed handoffs and missed requests. Subscription and usage costs matter, but so does the attention needed to supervise the agent.

The board can ask which responsibilities management has delegated, where human approval remains necessary and what evidence shows that the arrangement improves performance within the company’s risk appetite. Day-to-day permissions and workflow design remain management’s responsibility.

There is a cost to waiting indefinitely: the company also postpones learning where this type of delegation works. A bounded trial with appropriate data and reversible actions can build that knowledge. Expanding it should follow evidence, not the number of agents running.

My expectation is that more work will be assigned as an ongoing responsibility rather than as isolated prompts. That makes the identity and authority behind digital requests more important. I explore that consequence in whether AI agents are changing the rules of trust in email.

Based on official product documentation checked on 11 October 2026. This is an explanation and analysis, not a hands-on comparison or an independent performance benchmark. Availability and product controls can change.