We’re Building an AI Operating System That Can Move

By fast2future · August 9, 2026 · Build-in-public series

Most AI demos make the same quiet promise: pick the right model, connect a few tools, and the rest will take care of itself.

We are building toward something more durable than that.

The goal at fast2future is a portable AI operating system: one that can move to a new computer, a new business, or a different model without taking private credentials, hidden machine paths, or unproven claims along for the ride. MCP — the Model Context Protocol — is part of the plumbing. It gives an AI assistant a standard way to discover and use tools, data, and services beyond the chat box.

But protocol support is not the product. The product is a trustworthy operating layer around it.

The idea: capability should travel; authority should not

The portable part of our setup is deliberately boring: a connector registry, setup-state schema, account-profile template, qualification notes, queue helper, verifier, and resource guard. They describe what a connector is for, which interface is preferred, how much access it should start with, what proof counts as “live,” and what must remain a human decision.

That package can move.

What does not move is just as important: passwords, API keys, OAuth sessions, provider accounts, absolute machine paths, and the process state of one particular computer. On a new host, the operator supplies their own approvals and credentials. The new host resolves its own repository root. The capability map stays the same; the authority is local and explicit.

That is the difference between portability and copying somebody else’s access.

Model-agnostic does not mean model-blind

We do not want the system to depend on a single model provider being present, cheap, or best at every job. The operating layer therefore treats models as replaceable workers behind stable policy and tool contracts.

In practice, that means a workflow can prefer a command-line tool for a deterministic task, an official API for a narrow unattended read, an MCP server when it exposes a safer tool surface, and browser automation only when a human-facing flow genuinely requires it. The model is selected for the job; the safety boundary does not disappear because the model changes.

This is not a claim that every model behaves the same. They do not. They differ in reasoning, context size, latency, price, tool calling, and failure modes. “Model-agnostic” means our connector definitions, evidence requirements, identity routing, and confirmation rules are not written as if one vendor will always be the answer.

What is working now

The foundation is real and checkable.

We have a 100-connector portfolio with a machine-readable registry, a consistent lifecycle (CATALOG, STAGED, TAP NEEDED, LIVE-READ, LIVE-GUARDED, DORMANT, or REJECTED), and an evidence rule that refuses to confuse a configuration file with a working integration.

We also have a setup queue that takes one connector at a time, a validator that keeps secret-shaped values out of the recorded state, and a resource guard that checks whether the host can safely admit another process before anything heavy starts. The default path is intentionally conservative: CLI first, then official API, then official MCP, with browser work as a last resort.

The system can also distinguish between “this connector is available in theory” and “this connector has successfully completed a read-only proof on this machine.” That may sound like paperwork. It is actually how we avoid a dashboard full of green checkmarks that represent optimism instead of evidence.

What is not working yet — by design

Most external connectors are not live. They are cataloged, staged, or waiting for an operator tap.

That is not a failure to finish the list. It is an honest description of reality. Gmail, a calendar, a CRM, a hosting provider, an analytics tool, or a model API can expose sensitive information or create real-world consequences. Before any one of them earns a live status, it needs the correct account, the narrowest useful scope, a local credential stored outside the repository, and a successful read-only health or list test.

Action surfaces are even stricter. Sending, publishing, spending, deleting, contacting people, and deploying remain separately gated. A system that can call a tool is not automatically allowed to use its most consequential capability.

There are practical constraints too. Some provider APIs require paid plans or keys. Some browser-only integrations are clumsy. Starting many temporary MCP servers can create unnecessary Node processes and RAM pressure. And a connector ecosystem changes fast enough that “installed once” should never be confused with “safe forever.”

Why we are taking the slower-looking path

The easy version of AI integration is a pile of tokens, tabs, and one-off scripts that work only on the machine where they were born. It looks fast until a model changes, a credential expires, someone needs to reproduce it, or an automation makes an expensive mistake.

Our version is trying to make the tradeoff explicit:

• Maximize useful capability, not unchecked permissions.
• Start with read and preview modes, not send and publish modes.
• Keep secrets off the repo and out of chat.
• Use evidence-backed states instead of implied readiness.
• Make the portable source layer the truth, not a machine-specific configuration file.

It is less cinematic than “connect everything.” It is much more likely to survive contact with real work.

The destination

The destination is not an AI that has unlimited access. It is an AI operating system that can be installed anywhere, paired with the right model for the task, and given exactly the authority an operator intended — no more, no less.

That is the standard we are building toward in public: portable capability, local authority, and proof before promises.