Your Cloud AI Agent Is a Dependency Someone Else Controls

Your Cloud AI Agent Is a Dependency Someone Else Controls

On Thursday, 8 October 2026, AI agent startup Manus said it had raised more than $500 million. Boyu Capital and IDG Capital led the round, and existing shareholders Tencent, HSG and ZhenFund also put in money. Manus, whose parent company is Butterfly Effect, did not disclose its post-funding valuation. Bloomberg reported in September that Manus was set to double its valuation to $4 billion.

It is the company's first funding round since Chinese regulators blocked Meta's roughly $2 billion acquisition of Manus. Meta had already begun integrating Manus' team and technology into its own. I am not going to guess how that story ends. The part that matters to anyone running an agent is simpler: the people using Manus had no say in any of it, because a cloud agent's roadmap is not yours to keep.

Why I run an open-source AI agent instead of renting one

A hosted agent is a rented dependency. When you use one, you pay for access to a service that runs on someone else's servers, under someone else's business plan. That is fine for a chatbot you open twice a week. It is a different matter once the agent files your invoices, sorts your inbox or pushes code.

Look at who had a hand on the switch for Manus. First there was a would-be owner, which had started folding the team and technology into its own products. Then there was a regulator: the National Development and Reform Commission said it would "prohibit foreign investment in the Manus project". Now there is a new set of investors, whose money shapes what the company does next. None of them is a villain, but none of them is you.

Analysts read the raise as a sign of stability. Dan Wang, China director at Eurasia Group, said it shows "the short-term fallout of the Meta case has been contained and investors are willing to back Manus as an independent company." Han Lin, China country director at The Asia Group, said: "The immediate task for Manus now is proving scale, profitability and regulatory alignment."

Read that second quote as a customer would. Scale, profitability and regulatory alignment are reasonable goals for a company, and work on any of them can change prices, features or where a service is offered. You get no vote on those trade-offs.

Product direction moves too. Earlier this month, Manus said it had resumed independent operations. Since then it has shipped Manus 2.0, built on a new in-house execution system called Cascade. A new engine under an agent you depend on is a change you did not schedule.

This applies to every hosted agent, not only to Manus. Funding, ownership, regulation and pricing are four switches, and any one of them can stop your workflow. Run the agent on your own box, from code you keep a copy of and against a model you have downloaded, and none of those switches can reach you. The project can still change direction upstream, but the version you run keeps working.

"Built on open source" is not the same as "run by you"

The story gives us a clear example of the difference. In early September, Meta launched its own personal AI agent, Muse, which was reported to be modelled on the open-source AI agent OpenClaw. The model behind Muse, though, is not open. The agent design may have open roots, but the part that does the thinking stays on Meta's side.

That gap matters more than the label. Open code in the agent loop shows you how the agent plans and calls tools. It tells you nothing about who serves the model, what gets logged, or whether the service will still exist next year. I made the same point about Meta's devices in open hardware is not an open assistant: owning the box does not mean you own what runs behind it.

Before I trust any agent with a real job, I check four things.

  1. The licence. Read the LICENSE file in the repository, not the landing page. A licence approved by the Open Source Initiative, such as MIT, Apache-2.0 or AGPL-3.0, lets you keep running and forking the code you have. A "source available" licence, or a custom one with use restrictions, does not give you the same promise.
  2. Whether the weights are available. An open agent that only talks to one hosted model is still a hosted agent. Check that it can point at a model whose weights you can download, either through a local model server or through an OpenAI-compatible endpoint you run yourself.
  3. Whether it runs with no outbound network. Create an isolated network with docker network create --internal agent-test, put the agent on it next to a local model server, and give it a small task. If it refuses to start, waits on a licence check or crashes because its telemetry cannot connect, you have found a hidden dependency.
  4. Whether you can revoke its credentials. Every token the agent holds should be one you issued yourself, scoped to one job, and you should be able to kill it in under a minute. Manus' new Cue app gives each agent its own email address, phone number and mobile wallet. Whatever you think of that idea, ask who can switch those off, and how fast.

What a self-hostable agent stack looks like on my own box

Nothing exotic. Two containers, one private network, a file of tokens and a habit of reading logs. Here is the setup I use, written as a Docker Compose file. The agent image is whichever open-source agent you picked. Pin it to an exact version tag or digest instead of latest, so upstream changes arrive only when you choose them.

services:
  model:
    image: ollama/ollama   # pin a tag you have tested
    volumes:
      - ollama-models:/root/.ollama
    networks: [agent-net]

  agent:
    image: your-agent-image:v1.2.3   # pin an exact version
    read_only: true
    tmpfs: [/tmp]
    cap_drop: [ALL]
    security_opt: ["no-new-privileges:true"]
    env_file: ./agent.env
    environment:
      MODEL_URL: http://model:11434   # variable name depends on your agent
    volumes:
      - agent-work:/work
    networks: [agent-net]
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "5"

networks:
  agent-net:
    internal: true

volumes:
  ollama-models:
  agent-work:

Here is what each piece does.

  • A container with nothing to spare. read_only, cap_drop: [ALL] and no-new-privileges limit the damage if a poisoned web page or email talks the agent into running something. The container cannot change its own files or gain extra privileges. The only places it can write are /tmp and one named volume.
  • A local model server. Ollama listens on port 11434 inside the private network. There is no ports: line, so nothing is exposed to your LAN. Because the network is internal, the model server cannot download models either, so pull them first. Set internal: false, run docker compose up -d, then run docker compose exec model ollama pull llama3.1:8b. After that, set it back to true and run docker compose down && docker compose up -d. If you have not run a model server before, I covered the basics in renting a model versus owning one.
  • Credentials you can revoke. agent.env holds only tokens made for this agent, and its permissions are chmod 600. For example, a fine-grained GitHub token limited to one repository with an expiry date, or a separate mailbox with its own app password, never your main account. If the agent misbehaves, revoke the token at the provider and the agent loses access at once, whatever state the container is in.
  • No host mounts. The agent writes to a named volume, not to your home directory. Never mount /var/run/docker.sock into an agent container, because access to that socket is effectively root on the host.
  • Network egress you control. With internal: true, the agent cannot reach the internet at all. If a job really needs one outside API, add a small forward proxy such as Squid. Attach it to both the internal network and an external one, give it an allowlist of domains, and point the agent at it with HTTPS_PROXY. That way, every domain the agent can reach is one you added on purpose.
  • Logs you actually read. The logging options cap log storage at about 50 MB. Once a week I run docker compose logs --since 168h agent | less and check which tools it called, which hosts it tried to reach and which actions failed. If you never read the logs, you don't know what the agent has been doing.

The honest costs of running it yourself

Self-hosting an agent is not free, and it does not match the best hosted products on every count. Here is what you give up.

  • Model quality. A model that fits on one consumer GPU or a mini PC is weaker than the strongest hosted models. The gap shows most on long multi-step tasks, where one bad step derails the rest. Expect to write tighter instructions and to split jobs into smaller pieces.
  • Polish. You get no slick app and no agent with its own phone number. Setup means a Compose file, a README and some trial and error.
  • Vendor support. When it breaks late at night, all you have is the issue tracker, the logs and your own time. Updates are your job too, because pinned versions do not patch themselves.
  • Hardware and power. You pay for these up front instead of monthly, and a GPU running all day shows up on the electricity bill.

Open-source projects can stall or change direction too. The difference is what you are left holding: the code, a licence that lets you run and fork it, the model weights on your disk and the last version that worked.

The main thing you keep is the point of this whole story. Your workflow keeps running when the vendor's funding round, owner or regulator changes. Your data stays on your box, and you decide when to upgrade.

I do not run everything locally. My rule is simple: if losing a workflow overnight would hurt, it runs on my hardware. One-off research or a quick draft can go to a hosted tool, because if that tool disappears, I lose nothing I cannot redo.

Getting started, or getting help

Start small: one agent, one job, one revocable token and an internal network. Read the logs for a week before you give it anything more. That is enough to find out whether a self-hosted agent can handle the work you have been renting.

If you would rather have someone set up and harden this stack for you, from the Compose file to the egress allowlist, take a look at my services page. Fiverr: hiteshsaini459 · Upwork: hiteshsaini25