What are AI agents for business — really?

“Agent” has become the most inflated word in software. It currently covers: a chatbot with a persona, a macro with a marketing budget, a browser script that clicks things until something breaks, and — occasionally — the real article: software that watches for a condition, decides, and acts on your systems within limits you set. If your company is budgeting for “agents” in 2027, the first deliverable should be a definition sharp enough to reject three of those four. Here is ours.

The old way: agents as vibes

The prevailing failure isn’t bad agents; it’s undefined ones. Vendors demo “an agent that handles your invoices” and the demo elides every question that decides whether you’d let it near your invoices: what exactly triggers it, what exactly it can read, what exactly it can change, what it does when unsure, and where the record lives when it’s done. The old way answers these with a dashboard and a shrug. Then the pilot ends and nobody can say what the agent was, let alone hand it to the next team.

A working definition: four fields, not a personality

Strip everything decorative and a business agent is exactly four decisions:

• Instructions — what it’s for, in plain language a colleague could read and correct.
• A trigger — when it runs: manually, on a schedule, when something changes, or only when mentioned.
• A scope — which folders and applications it may read, and separately, which it may write. Everything outside the write scope stays untouchable by it.
• An autonomy level — ask first for everything; act on safe reads and small writes but ask for big ones; or run fully autonomous.

Anything sold as an agent that cannot show you these four fields is asking you to govern a vibe.

The CloudTop move: the agent is a file

In CloudTop — the AI workspace you own — those four fields aren’t a mental model — they are literally the contents of the agent. An agent is a small, readable file in the workspace: purpose, instructions, trigger, read scope, write scope, autonomy level. That one design decision quietly solves the problems the dashboard model can’t:

• Reviewable: a manager reads the file and knows exactly what was authorized — the file is the authorization.
• Shareable and improvable: copy it, adjust the scope, hand it to another team — the shared-capability story, applied to agents.
• Versionable and inheritable: it can be diffed, exported, and kept — when its author leaves, the file stays.
• Governed like everything else: its scopes are folders, its actions land in the same audit stream as human ones, and when it acts on records it does so the propose-and-commit way — through the application’s own forms and validation.

The agent lifecycle: from experiment to institution

Because an agent is a file, it has a lifecycle other formats can’t offer — and managing agents becomes managing documents, a skill your organization already has. It starts as an experiment: drafted in a personal folder, scoped tight, autonomy on “ask first,” run manually a few times while the instructions get honest. It becomes a pilot when the trigger goes live and the run history starts accumulating — still narrow, still watched. It becomes an institution the day it moves into a shared folder: now it’s reviewable by the team, copyable by the next one, and improvable by anyone with access — with version history recording who tightened what. And it retires cleanly: export the file, archive it, and the record of what it did stays in the audit stream. Two habits keep the lifecycle healthy. Re-read your agents quarterly the way you’d re-read a standing purchase order — scopes drift out of date faster than instructions do. And when someone leaves, their agents don’t: reassign the file’s ownership, skim its scopes, and the institutional knowledge keeps running — which is precisely the property no per-account “agent” product can offer, because there, the account was the agent.

Chatbot, in-app assistant, agent — one honest taxonomy

A chatbot answers when spoken to and touches nothing. An in-app assistant helps inside one surface, with you present. An agent has standing permission to act within a scope — which is why the scope, not the intelligence, is the thing to interrogate. The industry markets upward along this ladder; your governance should read downward: before asking “how smart is it?”, ask “what exactly did we permit, and where is that written?” In a workspace you own, it’s written in a file, in your folder, in language your team already speaks. The four problems that make any of this safe to run at all — real app functions, row-level governance, device-held credentials, shared memory — are the subject of the four-problems piece, and they are where every agent conversation should start.