Self-hosting gives you a machine. Managed gives you a working agent.

What your team owns in each model

The agent is only one part of the system.

A useful agent needs a place to run, a way to reach approved tools, a record of what it did, and a safe way to stop when context is missing. A demo can skip most of that. Day-to-day work cannot.

Who gets the call when it stops working?

That is the clearest test of a DIY setup. A self-hosted agent can be perfectly reasonable when there is a named technical owner who has time, authority, and a reason to operate it. It becomes less reasonable when the answer is a marketing lead, a founder, or the person who first got it running on a Friday afternoon.

The problem is not that a Mac mini is bad hardware. The problem is that hardware creates an ownership story. Someone becomes responsible for network changes, OS updates, browser sessions, encrypted secrets, access requests, and the strange little failures that arrive after a system has been used for a month. The work is real even when it does not show up on a budget line.

People trust agents that are legible.

Business teams do not need an agent to look magical. They need it to be clear. A good operating model tells the team what sources the agent used, what it prepared, what it could not verify, and where it stopped for approval. This is how an agent earns more responsibility over time.

Self-hosting does not prevent that. It simply means the team must build or maintain those habits and surfaces itself. A managed model should provide them as part of the service. If an agent sends a result with no evidence, changes something without a trail, or fails silently, the team will stop using it no matter how smart the model is.

Hosting is not a shortcut around approval rules.

A safe agent setup begins with scope. What can it read? Which tools can it use? What does it prepare by default? Which actions always need a person? Those answers matter more than whether the box is in an office or a cloud account.

For teams evaluating a managed service, ask for plain answers about access, records, failure handling, and how permissions are changed. For teams evaluating self-hosting, ask the same questions internally. The technology choice does not erase the operating work. It only decides who carries it.

DIY is a fit when the ownership is deliberate.

There are teams that should build and operate their own agent environment. They may have a platform engineering group, a mature security program, specialized deployment requirements, or a product reason to make agent operations part of their core capability. Those teams are not looking for a shortcut. They are making an investment.

The mistake is treating every team as if it has that same reason. If the goal is to reduce manual marketing work, get a reviewable draft faster, or keep a workflow from falling through the cracks, a managed agent often gets there with far less overhead.

Choose the model that matches the job.

Choose self-hosting when owning the platform is part of the strategy and the team has clear operational ownership. Choose a managed agent when the goal is to get useful work moving without turning the business team into the support desk. Start with a workflow that has a clear input, a reviewable output, and a meaningful human approval point.

The right first job is usually unglamorous. It may be gathering context for a launch, checking a set of pages, preparing a follow-up, organizing a decision brief, or keeping a handoff from going cold. Those jobs create proof. After that, the team can decide whether more access or more automation is warranted.

Prove the operating model before expanding the agent.

The fastest way to make a bad decision is to start with a broad promise like “handle our marketing operations.” Start smaller. Pick one workflow with a known source of truth, a repeatable next step, and a person who can judge the result. For example, the agent can gather recent account context and prepare a follow-up draft, check a set of live pages against a brief, or turn a meeting into owners and next steps.

In a self-hosted model, that first workflow is also a test of the team’s ability to operate the environment. Can it reliably access the right systems? Does it preserve a clear record? Who responds when the scheduled run does not finish? In a managed model, it is a test of the service. Does the provider help define the work, configure the rules, and keep the agent useful after the first version?

Either way, do not measure success by how autonomous the agent appears. Measure whether people trust the output, whether the review step is clear, and whether the workflow actually removes a recurring piece of manual coordination. That is a much better basis for deciding what the agent should carry next.

Make the ownership explicit.

Write down the name of the person or team who owns the agent when it is unavailable, when an access request arrives, when a scheduled workflow does not complete, and when the workflow itself needs to change. If that owner is clear and resourced, self-hosting may be a sensible choice. If nobody can take that on without dropping their actual job, the managed route is probably more honest.

Then write down the first workflow in plain language. What starts it, which sources it needs, what finished work looks like, and where a human must decide. This turns a deployment choice into an operating choice. It also makes it much easier to compare a DIY setup with a managed service on the thing that matters: whether the agent takes real work off the team’s plate.

Do not confuse access to an agent with ownership of an agent operation.

A DIY setup can give a team access quickly. Operating it well is the longer commitment. A managed model can give the team the same kind of capability while moving the runtime, maintenance, and recovery burden to a provider. The better choice is the one that leaves the right people responsible for the right work.