Cloud Agents for Knowledge Work

Most AI tools for knowledge work today run inside one person's local workflow. You open a chat, paste context, ask for a draft, and approve or redirect the answer as it happens.

That works well when one person is actively working through a task. It does not work as well when the task spans a team, a client, a project folder, a meeting transcript, a CRM, a spreadsheet, and several rounds of review.

A client request may start in email. The context may live in Slack. The source files may sit in Drive. The facts may be in a spreadsheet. The final output may need to become a memo, a deck, a dashboard, or a follow-up sequence. The work does not live in one prompt. It lives across systems.

Cloud agents move that work to remote infrastructure. The agent has access to the right files, tools, workflows, memory, approvals, and review path. It can work while no one has the right tab open. It can start from Slack, email, a ticket, a schedule, or an API. It can return with a finished artifact for review.

The core idea is simple.

Cloud agents are not just local assistants running somewhere else. They are a different category, and the differences compound.

What a cloud agent actually is

A cloud agent runs on remote infrastructure. It has its own workspace, browser, tools, files, and memory. It connects to the systems a team already uses.

For knowledge work, that means email, Slack, Google Drive, Microsoft 365, Notion, Airtable, HubSpot, Salesforce, data rooms, spreadsheets, CRMs, calendars, ticketing systems, and internal knowledge bases.

You communicate with it the way you would communicate with a remote teammate. You send a task. It gathers context. It works through the steps. It produces an artifact. You review the result.

The local assistant model is collaboration in the moment. A person and an AI share one task while the person is present.

The cloud agent model is delegation. The person describes the outcome, the agent works independently, and the person reviews the output.

Both models matter.

Local assistants help individuals think, draft, and revise. Cloud agents help teams get work done across systems, time, and people.

More people can request work

Most organizations have a hidden backlog of small knowledge work.

A partner wants a cleaner client brief. A manager wants a weekly account summary. A sales lead wants a prospect dossier. A finance lead wants a reconciliation. A researcher wants a source-backed report. A support lead wants a pattern analysis from tickets. A tax advisor wants a planning memo.

Many of these tasks do not happen because the person who sees the need is not the person with the time, tools, or context to do it. Filing a ticket feels too heavy. Asking an analyst interrupts higher-value work. Doing it manually takes too long.

A cloud agent removes that extra step.

The person who sees the need can describe the work and move on. The agent gathers context, creates the artifact, and routes it for review.

This is a major shift. AI stops being a private assistant for one person and becomes a shared work layer for the organization.

One agent can work across systems

A local assistant sees what the user gives it.

A cloud agent can be connected to the organization's systems. It can know where files live, which templates matter, which examples are approved, which tools it can use, and which approvals are required before work goes out.

That matters because knowledge work is rarely contained in one source.

A client memo may need a call transcript, a proposal, a contract, a data export, a pricing sheet, and prior email context. A quality review may need raw data, client notes, past decisions, and a reporting standard. A strategy deck may need research, internal positioning, examples, and financial assumptions.

When the agent can work across those systems, the task changes.

The user does not have to gather every file first. The agent can assemble the work packet, cite what it used, and show its reasoning.

That is the difference between "write me a draft" and "complete the work."

Work can run in parallel

Local AI work usually happens in real time. You watch the model respond. You edit. You ask for another pass. You keep steering.

That makes sense for unclear work. It is useful when judgment is still forming.

But a lot of knowledge work can be delegated once the desired output is clear.

A team can ask for three versions of a market map. A manager can ask for weekly briefs across ten accounts. A diligence team can ask agents to review separate folders and merge findings. A finance team can run multiple reconciliations. A client team can ask for parallel report drafts with different assumptions.

Cloud agents make that natural. Each session can run in its own environment. Each session can produce its own artifact. A reviewer can compare the results and decide what to keep.

The limiting factor becomes review quality, not drafting time.

That means review has to become part of the product.

Events can start work

Knowledge work often starts from an event.

A client sends a file. A meeting ends. A form is submitted. A support issue crosses a threshold. A CRM stage changes. A contract is uploaded. A weekly report is due. A new dataset lands in a folder.

A cloud agent can start from those events.

The event gives the agent context. The workflow tells the agent what to do. The review path tells the agent where to send the output.

For example, a new client email can start a summary and suggested reply. A meeting transcript can start a follow-up plan. A new spreadsheet can start a data quality review. A CRM update can start an account brief. A weekly schedule can start a pipeline report.

Event-based workflows need controls. Permissions, budgets, filters, approval steps, and run limits matter. A noisy workflow should not create a flood of agent runs.

With those controls in place, events become work triggers.

The organization stops waiting for someone to remember the next step.

Skills make repeated work easier

Once a team teaches an agent how work should be done, that knowledge should be reusable.

This is where skills matter.

A skill tells the agent how to handle a class of work. It can include source order, review standards, writing style, tool use, approval rules, examples, and known failure modes.

For a client brief, the skill might say which sources to check, how to cite facts, what tone to use, and what must be reviewed before sending.

For a data review, the skill might say how to map fields, how to separate hard errors from judgment calls, how to write row-level notes, and how to report findings.

For tax strategy, the skill might say how to separate client facts from assumptions, where expert judgment is required, and how to format the final memo.

This is how cloud agents get better inside a company. The value is not only that one person can use one tool. The value is that the organization can encode how work should be done and reuse it.

Review becomes the bottleneck

Cloud agents create more output.

That is useful only if review improves too.

If every agent run creates a pile of untrusted drafts, the team has not gained much. People either rubber-stamp the work or spend too much time cleaning it up.

A serious cloud agent system needs review built in.

The reviewer should see what the agent read, what it produced, what sources it cited, what assumptions it made, what it was unsure about, what changed from the prior version, and what approval is needed.

The review step should not be a dead end. It should teach the system.

If a reviewer changes a conclusion, rejects a classification, adds missing evidence, or rewrites a section, that correction should be captured. The system should know whether the correction was a true error, a preference, or missing context.

That is how review becomes an improvement loop.

Self-improvement is the next step

A cloud agent that does not learn from corrections will repeat the same mistakes at scale.

The next step is self-improving cloud agents.

The system needs three things.

Expert feedback. The people who know the work must steer what the system learns. Their corrections show which errors matter.

Production traces. The system must preserve the path from source material to output. It needs to show what the agent saw, what it decided, and what the reviewer changed.

Evals and skill updates. Repeated corrections should become tests and instructions. The next run should be measured against the failure patterns found in prior runs.

This is the same pattern described in OpenAI's article on building self-improving tax agents with Codex. The key idea is that production corrections become structured signals, then evals, then scoped improvement tasks. The agent does not improve because someone says "do better." It improves because the system gives it a clear target and a way to test progress.

That pattern applies directly to knowledge work.

A corrected memo can improve the memo skill. A rejected data classification can improve the review workflow. A rewritten client update can improve the writing standard. A missed source can improve retrieval. A recurring approval issue can improve the workflow gate.

The work itself becomes the training surface.

Where the agent connects

A local assistant connects to whatever the user pastes into the chat.

A cloud agent connects to the tools the team already uses.

Slack and Teams can start tasks and send updates. Gmail and Outlook can provide client context. Google Drive and SharePoint can hold source files. Notion and Confluence can hold internal knowledge. HubSpot and Salesforce can provide account context. Airtable and spreadsheets can provide structured data. Calendars and meeting tools can provide transcripts and follow-ups.

MCP and similar tool standards make this easier to extend. The agent can use approved tools instead of relying on copied context. It can pull the record, inspect the source, and cite the result.

Because the agent runs in the cloud, these integrations can be configured once for the organization. Individual users do not need to wire every tool into their own local setup.

What this means for pricing

Local assistants are often priced per seat because one person uses the tool in their own workflow.

Cloud agents are different.

Work can start from many places. A Slack request, a client upload, a CRM change, a scheduled report, or a manager request can all start an agent session.

That does not map cleanly to one user seat.

The unit of value is the work completed.

A reviewed memo. A cleaned dataset. A client-ready report. A diligence packet. A weekly account brief. A reconciled spreadsheet. A completed support analysis. A tax planning draft ready for expert review.

The pricing model should reflect that.

The system should be measured by output quality, review time saved, acceptance rate, repeat usage, and improvement over time.

How teams get results

Deploying cloud agents takes more than giving everyone access.

Teams get better results when they assign specific work, write skills, connect the right systems, define review gates, and measure output.

The best early workflows are repeated, evidence-heavy, and expensive to do manually.

Good examples include client-ready research briefs, meeting follow-ups, data cleaning and quality review, diligence packet review, CRM cleanup, account summaries, tax strategy support, support ticket analysis, compliance checks, and weekly operating reports.

These tasks are clear enough to delegate and important enough to review.

Teams that only buy AI seats and wait for adoption usually get weaker results. Someone has to decide what work the agents should own, how humans should review it, and how corrections should improve the next run.

Two ways to use agents

Use local assistants when you want to think through a task in real time.

Use cloud agents when the work is clear enough to delegate and review later.

A local assistant is useful for brainstorming, editing, exploring, and making decisions while you work.

A cloud agent is useful for work that needs source gathering, tool use, artifact creation, review, and follow-through.

The strongest teams will use both.

They will keep humans close when judgment is still forming. They will use cloud agents when the task can run against clear instructions, evidence, and review gates.

Cloud agents as shared knowledge-work infrastructure

Cloud agents run in a separate environment. They connect to team tools. They accept work from multiple entry points. They produce artifacts for review. They preserve traces. They improve from corrections.

That makes them shared infrastructure for knowledge work.

They give partners, analysts, operators, managers, support teams, finance teams, and advisors a way to request real work without gathering every source manually or learning a new technical workflow.

Local assistants help people while they are working.

Cloud agents help organizations get work done when no one has the right file open.

Self-improving cloud agents go one step further.

They help the organization get better at the work each time it is reviewed.

That is the category.

That is the Opulent thesis.