Tycoon adds an agent to its workforce as a parameter, not an integration

Tycoon is a company operating system built around an AI CEO. A founder gives it a goal; Tycoon plans the work, delegates each task, applies approvals, judges the result, and reports back. That coordination is the product, and it is where the company competes.

None of it is reachable until something underneath can actually run an agent. Every delegated task needs a real computer — a filesystem to write to, a shell to run, a network to install from — held for the length of the task and released after. It needs a stream the interface can render while the work happens, a workspace that survives the session, and something that notices when a machine dies mid-turn.

That layer is invisible in a demo and unavoidable in production. It is also not where Tycoon is different from anyone else: no customer picks a company operating system because it runs a good sandbox pool.

Tycoon’s premise is that different work wants different workers. A research pass belongs to Claude Code on Claude Opus 5; a support sweep to Hermes on DeepSeek V4 Flash; a build job to Codex on GPT-5.6 Sol. Routing by task is the whole value of having an AI CEO at all.

Adopted separately, each harness arrives with its own authentication flow, process lifecycle, event format, state directory, model compatibility matrix, and upgrade path. A second agent is not the first integration done twice — it is a second thing that fails in its own way, on its own schedule, with its own on-call.

On AgentSky both choices are fields on one call — one names the harness, one names the model. The isolated cloud computer, the persistent workspace, one event contract for every harness, and recovery come with the agent instead of being assembled around it. Tycoon keeps no agent runtime of its own.

The clearest evidence ran on Tycoon itself. An agent named Darren — Tycoon’s AI CTO, running on this same API — built and launched AgentSky, wrote its Product Hunt post, and answers its product email.

It was not a demo lane. Darren used the same session API, the same streamed events, and the same persistent workspace as Tycoon’s customer work, which is what makes it evidence rather than a showcase.

Every agent task Tycoon runs in production — research, support, growth, code — is a session on this API.

When a new harness lands in the AgentSky catalog, Tycoon can put it on a task the same day: no new auth flow, no new event shape, no new upgrade path to absorb. Harness upgrades land on the platform side of the boundary rather than in Tycoon’s release notes.

The property matters most before it is needed. Betting on the wrong harness costs a config change instead of a migration, which is the difference between choosing an agent and marrying one.

The economics point the same way. Compute is metered by the second while an agent is awake and a parked agent bills none, so an idle roster is not a standing cost — which is what makes it reasonable to keep a wide one.

Tycoon is not building a better model picker. It is building a company where the work itself is delegated: people set the goals, agents carry them out, results come back to be judged.

That only compounds if the roster can keep growing while the integration stays one integration. Every harness that ships on AgentSky is another kind of worker Tycoon can hire the day it arrives.