Your teams ask for their own AI assistant. Once you start to look, you find three very different kinds of product. Some agents live inside a suite you already run. Model providers such as Anthropic and OpenAI give you SDKs to build your own. And open-source projects such as OpenClaw give you a complete autonomous agent to host yourself.

The names and the marketing sound alike. The architecture, the governance model and the answer to "who is liable when the agent gets it wrong" do not. This post sorts the three types so you can decide on the type first and compare features second.

What a personal AI agent is

A personal AI agent does multi-step work for one person. It does not only answer. It writes emails, creates tickets, commits code, researches and prepares meetings. The difference from a chatbot is the agent loop: the agent plans, calls a tool, checks the result and plans again, sometimes for minutes or hours, with little human input.

That loop is what makes agents useful. It is also what makes them a governance topic. Every tool call is an action in one of your systems.

Why the decision is hard right now

Adoption moves faster than control. Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5% in 2025 (Gartner, August 2025). In the same period, Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027 because of rising costs, unclear business value or weak risk controls (Gartner, June 2025).

Four problems show up again and again in our projects:

• Two risk profiles get mixed up. An agent embedded in one suite and a universal agent that can reach anything you connect are different risks, and they need different reviews.
• Consumption pricing hides the real cost. Credit and token models look cheap in a demo. Calculate how many prompts and tool calls your team will actually run before you sign.
• Autonomy without scope is a security risk. The more an agent may do on its own – shell access, sending email, approving payments – the more it matters who grants each permission and who reviews it.
• Nobody owns the log. If you cannot see afterwards what an agent did and on whose behalf, you cannot audit it, and you cannot learn from its mistakes.

The three types

Embedded suite agents are the easiest start if most of your work already lives in one platform. They see what the user may see and log what they do. Their limit is the edge of the suite.

Agent SDKs give you building blocks: an agent loop, subagents for focused tasks, tool connections through the Model Context Protocol (MCP), and hooks where you can stop the agent for human approval. You get control, and you also get the work of running it.

Self-hosted autonomous agents give you a finished, universal loop on your own infrastructure. They are the most flexible option and have the largest attack surface. There is no built-in enterprise governance layer. Scoping, permissions and audit are entirely on you.

Governance is the deciding dimension

Across all three types, the same three controls decide whether an agent is safe to let act:

• Approval per action. The agent proposes, a human approves anything that changes a system of record, sends something outside the company or costs money. Low-risk reads can run free; writes need a gate.
• A complete activity log. Every tool call, with input, output and the person the agent acted for. Without it you cannot answer an auditor, and you cannot find the cause of a bad result.
• More than one model provider. Models change fast. If your agent layer is tied to one provider, every price change or outage is your problem. A layer that can route to several providers keeps that choice with you.

How we test this ourselves

At XALT we run a self-hosted personal agent internally. It is built on the open-source project OpenClaw, which we use but do not maintain. It is connected to our Atlassian, Slack and messaging channels and takes on recurring work such as research, meeting preparation and status updates.

We chose self-hosting for data sovereignty and to fit skills to our own processes. The price is discipline: every new permission and every new channel is granted on purpose and documented. Nothing is granted automatically. That experience is the reason the governance list above is short and strict.

Summary

• Decide the type first. Suite agents, SDK projects and self-hosted agents solve different problems.
• Reach and governance trade off. The more an agent can do, the more scoping the operator owns.
• Calculate consumption pricing before you buy, with your real usage.
• Approval per action, a full activity log and a choice of model providers are the minimum for an agent that acts.
• Teams that live in one suite start fastest with its embedded agent. Teams that need sovereignty or reach across systems should look at an SDK project or a governed self-hosted agent.