DEV Community: Evanchen

Two kinds of agents: Pet and Cattle

Evanchen — Tue, 11 Aug 2026 13:12:37 +0000

I increasingly believe that agents will split into two camps.

They are not lighter and heavier versions of the same product, nor do they sit at different points on a scale of autonomy. People expect them to become entirely different things: one is expected to become “someone”; the other only needs to finish a certain kind of work.

mosoo calls these two kinds of agents Pet and Cattle.

Where these terms came from

Anthropic did not invent Pet and Cattle. The terms come from an old infrastructure analogy. We encountered them again in Anthropic’s 2026 article, Scaling Managed Agents: Decoupling the brain from the hands: a pet is a named individual that needs special care and cannot be easily lost, while cattle are interchangeable.

Anthropic’s article is about agent infrastructure. Its conclusion is to separate the brain, hands, and session so that containers and harnesses can be replaced, rather than binding all state to a machine that has to be nursed back to health.

mosoo borrowed the terms but pushed the question up to the product layer. We are not asking how servers should be managed. We are asking what people expect an agent to become.

Anthropic’s earlier Building effective agents also distinguishes workflows from agents. A workflow sends LLMs and tools down paths written in advance; an agent decides for itself how to proceed and which tools to use. This distinction matters because Cattle is not just a traditional workflow with a new name. It is still an agent.

Type one: Pet, an agent you cultivate

The clearest example of this kind of agent is OpenClaw, which broke out in early 2026. People expect it to feel more like Jarvis: a personal assistant with an identity.

It has its own special memory. Interacting with it is, in practice, a process of cultivating it. People often compare the experience to mentoring an intern, and they naturally start to see the agent as a digital employee.

This kind of agent carries heavy state. It is often already a proxy for a computer—or, more directly, the proxy for a machine. A large amount of external state is preserved through tools and memory. MCP and skills extend its capabilities. Memory in the filesystem becomes part of the agent itself.

Users do not treat it as an instance that can be freely generalized or replaced. A two-year-old MacBook Pro is usually more useful to you than one you just bought. The hardware did not become better; it accumulated your software, sign-ins, files, habits, and way of working. That is why computers and phones need cloning, migration, and restore. Pet agents will need the same things.

We have long believed that this kind of agent should be delivered—or distributed—across channels. You can talk to it in GitHub, move to Linear, Email, Slack, or Discord, and it should still know what happened before. A channel is an entry point; the agent behind those entry points should remain the same.

Take an FAQ support agent. The customer problems it solved in Discord, the issues it handled on GitHub, and the work it recorded in Zendesk or Slack should all shape how it responds next. This is not one bot per channel. It is one agent, with one identity and memory, distributed to many places.

This agent may also receive permissions that resemble those of a natural person or social citizen. A user may give it a dedicated email address and its own credentials, then let it access payments, email, calendars, or internal systems. It may hold only a subset of that person’s permissions, or something close to the full set.

Pet users therefore care about token spend and whether subscriptions can lower the cost of long-term use. They care whether memory can be migrated, whether credentials are safe, and whether the agent remains “the same one” after moving to another machine. These are not deployment details. They are the core product experience.

Type two: Cattle, an agent pipeline that replaces a workflow

To understand Cattle, start with the workflow.

A workflow is a process pipeline. A person defines the procedure for a recurring problem in advance and specifies what should happen at each node. It often begins as the method of an experienced operator, then gets assembled in a low-code tool such as n8n or Dify. A few LLM nodes may handle steps that need reasoning, but the whole thing remains a fixed process.

Cattle is meant to replace that earlier generation of workflows.

It is a stateless agent. “Stateless” does not mean a task has no context. It means the agent does not depend on an irreplaceable, long-lived identity. The jobs it consumes, their type, and their input are highly consistent. Its required tools are fixed, and it works inside a controlled problem domain. When one run ends, a fresh instance can handle the next job of the same kind.

It behaves like a more flexible and free processing pipeline, with more room for reasoning and less dependence on a fixed path. PR audits, ticket triage, and refund requests are typical examples. We can constrain the permissions, input, and expected outcome without enumerating every step the agent must take.

Its mental model is closer to the imagined end state of autonomous driving: instead of continuing to encode “stop on red, go on green” as a growing set of if-else rules, an end-to-end system built around a vision model drives within a defined boundary. This analogy does not mean agents need no guardrails. It means the core capability shifts from “a person wrote the full path” to “the model chooses a path inside a controlled domain.”

Cattle users do not want to cultivate the agent, and they do not care which instance completed a particular job. They care about throughput, repeatable outcomes, whether failures can be rerun, whether permissions stay narrow, and how much each job costs. Its natural consumption model is an API token, with the agent embedded as a processing step inside another system.

The same support agent can be two entirely different products

Pet and Cattle are not determined by the industry, the model, or the name of the task. They are determined by the continuity users expect and the permissions the system is prepared to grant.

	Pet	Cattle
User relationship	I am cultivating “it” over time	I am repeatedly invoking a capability
State	Identity, memory, and environment accumulate	Each job starts from controlled input
Distribution	The same agent appears in many channels	A pipeline embedded at one system boundary
Permissions	Delegated personal permissions, potentially broad	The minimum permissions for one class of work
Cost model	Tokens, subscriptions, and long-term ownership	API usage and cost per job or outcome
Failure recovery	Clone, migrate, and restore “the same one”	Discard the instance and rerun the job

The FAQ agent above is a Pet if it needs to remember its long-running work across Discord, GitHub, Slack, and Zendesk. An execution unit that processes a single refund from an order, a policy, and a customer request is closer to Cattle. Both may be called a “support agent,” but they are not the same product.

Why mosoo implements both Agent Types

mosoo currently implements them as two Agent Types: Assistant Agent (Pet) and Task Agent (Cattle).

Pet keeps a stable working environment so that state can accumulate across sessions. Cattle creates a clean working environment for every run and releases it when the job ends. The current boundary is documented in the mosoo Agent Type PRD.

I also know that putting both choices in a single Agent Type selector will not be the final, correct product design. They serve two different kinds of users, with different buying, authorization, deployment, and cost models. mosoo has implemented the runtime boundary first. We will keep clarifying the product boundary over time.

This will become a dividing line across the agent industry

I believe the industry will explore this question repeatedly throughout 2026, and the distinction will gradually become clearer.

It will create two camps in investment maps. It will create two camps in agent infrastructure, and two camps in agent-native apps.

Companies building for Pets need to solve identity, long-term memory, delegated credentials, cross-channel distribution, backup and cloning, and the trust that gradually accumulates between a person and an agent. They are delivering something closer to a digital employee.

Companies building for Cattle need to solve isolation, evals, reproducible execution, concurrency, APIs, least privilege, auditing, and unit economics per task. They are providing a new kind of computation and processing capacity.

Neither path is more “agentic” than the other. The value of a Pet accumulates with time and use. The value of Cattle comes from being replaceable again and again while its outcomes remain reliable.

The next time we evaluate an agent product, perhaps we should not ask only what it can do. We should first ask: do users expect it to become someone, or do they only expect it to complete something?

Originally published on mosoo.

How ghfind turns a Mosoo Agent into a project evaluation feature

Evanchen — Mon, 10 Aug 2026 09:58:13 +0000

ghfind does not hand its entire product to an Agent. It delegates one feature that genuinely needs open-ended research—the deep evaluation of public GitHub repositories—to a published Mosoo Agent. GitHub account scoring, job orchestration, result validation, and the product interface remain ghfind's responsibility.

That boundary answers the most important question in Agent adoption: Mosoo does not rebuild the application's business logic. It lets the application call an Agent with tools, a sandbox, and a managed lifecycle as a backend capability.

What is ghfind?

ghfind is an open-source product for scoring the value and trustworthiness of GitHub developers. The homepage roast calculates a reproducible account score from public GitHub data. It does not use an Agent.

ghfind also evaluates projects. A user submits a public repository and, optionally, a branch, tag, or commit. ghfind returns a structured judgment across real demand, effectiveness, onboarding experience, and value density. That work requires reading source code, documentation, and project history—and sometimes verifying installation, builds, and core flows—so it is a better fit for an Agent.

What does Mosoo do here?

ghfind publishes a cattle Agent carrying its project-evaluation Skill on Mosoo. Mosoo supplies the reusable runtime capabilities: an isolated sandbox, Agent harness, tool execution, Run lifecycle, public events, and output files. ghfind does not need to maintain its own model loop, tool runner, or sandbox scheduler.

The real path for one evaluation is:

The browser submits a repository URL to ghfind.
ghfind's Go worker calls POST /agents/{agentId}/threads with a stable idempotency key and persists the Thread and Run IDs.
Mosoo starts the published Agent in an isolated sandbox. The Agent inspects the repository against ghfind's rubric while emitting Run and tool events.
The Agent commits three files: analysis JSON, evidence JSON, and a Markdown report.
ghfind downloads the files, validates them against its business schema, persists the result, and renders a native result page.

The Mosoo token stays in the ghfind backend. The browser sees ghfind's validated product result, not Mosoo's internal runtime data.

The boundary between Agent and application

In this design, Mosoo owns the reusable Agent runtime. ghfind owns the product definition.

The responsibilities that should stay in ghfind include the project rubric, repository submission and authorization, durable RabbitMQ jobs and concurrency, business retry policy, artifact size limits, result schema, leaderboards, and UI. Its headline account score is especially important: it is a deterministic scoring core locked down by unit tests and has nothing to do with the Mosoo Agent.

The responsibilities Mosoo should absorb are the protocol glue every Agent App would otherwise repeat: Thread, Run, event, and file types; authentication and error envelopes; idempotent requests; a resumable Run watcher; and a stable association between a Run and its output artifacts.

The current integration cost

ghfind's implementation also reveals what Mosoo still needs to provide. At b7eee13, the production Go backend maintains a 564-line handwritten Public Thread client. The file explicitly says it mirrors a separate 427-line TypeScript implementation.

Three workarounds stand out:

The client fetches only the latest 100 events. It parses truncated but neither pages older history nor surfaces truncation to the caller.
The worker polls the Thread, detects terminal states, schedules backoff, and restores a Run after queue redelivery.
After completion, the client scans the full Thread file list and finds results by three agreed filenames; it cannot obtain structured artifact IDs directly from the Run.

These observations are now recorded in Mosoo #489, which tracks publishing and extending the existing Public Thread client instead of creating a second SDK. The stable Run-to-artifact association is tracked separately in #505.

The reusable lesson

The safest way to add an Agent to a product is not to let the Agent take over the whole application. Find the feature that actually requires open-ended reasoning, tool use, and isolated execution, then put that work in a published Mosoo Agent. Keep user identity, business state, deterministic rules, and final presentation in the application.

ghfind's project evaluation demonstrates that boundary: Mosoo makes the Agent runnable, observable, and able to deliver files; ghfind turns those capabilities into a product feature users can understand and choose to use.

Originally published at mosoo.ai.

From model calls to agent tasks

Evanchen — Sat, 01 Aug 2026 08:31:15 +0000

Every generation of AI API gives developers a new primitive. Completions returned text. Chat APIs added structured messages. Tool calling let models request actions.

Each step moved more intelligence behind the API. But the application still owned the loop around it: tools, permissions, environment, state, retries, and the product experience.

Modern model APIs now include hosted tools, stored state, and background execution. They are useful building blocks. They still do not run your product-specific agent with its own environment, credentials, files, and lifecycle.

Local agents proved the runtime

Claude Code and Codex changed the experience because the model was no longer alone. It had a filesystem, shell, git, skills, and tools inside a real working environment.

That makes a familiar prototype possible. Point a coding agent at a repository, let it pull data and run an analysis, then feed the result into your own web page. The workflow can come together in one sitting.

The next request arrives naturally: move it to the cloud, run it on a schedule, run jobs concurrently, or turn it into a feature for teammates and customers.

Productizing agents exposes the runtime gap

When the workflow leaves the laptop, model intelligence is not the missing piece. Runtime is.

A production integration needs:

a sandboxed environment where the agent can run commands and work with files;
execution that can outlive one HTTP request;
durable Thread state and explicit file storage;
events that expose progress without leaking private runtime data;
permission gates, interruption, retries, concurrency, and usage controls;
secure custody for model keys and integration credentials.

These are not model capabilities. They are runtime and product responsibilities. If every team rebuilds them, an agent feature becomes an agent platform project.

The unit of work is a task

We should not call this a new unit of compute. One agent task may contain many model calls, tool calls, retries, and files. It is a unit of work.

Your product hands a task to a purpose-built cloud agent. A managed runtime executes it in a configured sandbox, while your product remains the user interface.

This is serverless as a consumption model: you invoke the agent without operating its execution infrastructure. It does not mean the task is a short-lived function.

A managed agent runtime, exposed as an API

That is the abstraction mosoo provides. Publish an Agent, call it from your backend, and mosoo handles execution, Threads, and files.

Create a Thread with an initial message. Follow its run status through the Thread, observe progress through Events, and exchange attachments and recorded artifacts through Files.

curl -X POST "https://cloud.mosoo.ai/api/v1/agents/$AGENT_ID/threads" \
  -H "Authorization: Bearer $MOSOO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "input": {
      "type": "user.message",
      "content": [
        { "type": "text", "text": "Analyze the commits from last week." }
      ]
    }
  }'

Poll GET /threads/{threadId}/events, or use /events/stream for Server-Sent Events. Your product can show progress, tool activity, results, and downloadable artifacts in its own interface.

API tokens are backend secrets. Your app remains responsible for end-user authentication, authorization, and mapping its users to mosoo Threads.

From local prototype to product

Every published Agent includes a copyable Instruction for LLM. It gives a coding agent the generated identifiers, endpoints, environment variables, and integration contract for that Agent.

Publish an Agent, copy its Instruction for LLM, and give your coding agent the exact contract it needs to integrate with mosoo.

Paste the instruction into Claude Code or Codex and let it wire the API into your backend. You still review authentication, data access, and the user experience like any production integration.

Local agents proved the value of giving models a real runtime. The next step is not a larger model call. It is a managed agent task that your product can start, observe, and continue through an API.

Try it at cloud.mosoo.ai, or read the code on GitHub: langgenius/mosoo.

Originally published on Mosoo Blog. Mosoo is an open-source managed agent runtime for deploying sandboxed agents behind an API.

The journey begins with an Imagine If.

Evanchen — Sat, 01 Aug 2026 08:25:25 +0000

Follow the notes upon the journey. At first sight marks one's destiny. Return lies within the hasty keys.

A few months ago, I was moving between customer sites, talking through our New Agent Design in Workflow.

The questions kept repeating: why not OpenClaw? How is this different from Hermes Agent?

It was not the first time I felt a little lost.

Eventually I realized the confusion was not about one tool. It was about a boundary we had not named clearly enough: when is Agent Work just a delivery, and when should it become part of a production system?

For many consumer scenarios, building a component library ahead of time is too expensive.

If the need is one-off, and you are not sure the same problem will appear again in three months, Claude Code or Codex is often enough. You do not need to abstract first. You do not need to build an app before delivering the result.

Sometimes I tell customers to make the problem smaller.

"This does not need to be so complicated. Claude Code can solve it. If the problem comes back, write a skill. That may be the smallest useful investment."

I still believe that.

But another thing slowly became visible: countless personal PCs started growing fragmented Agent solutions.

They were experiments, but also artifacts. They depended on local environments, Session History, context, file copies, MCP tools, and skills.

I can finish the task on my computer. If your environment matches mine, you can replay my experiment.

But if this is how Agent artifacts move, what are they? Fast-moving goods? A local performance that only works on one stage?

That was the real turn in our journey.

We are not trying to platform every piece of Agent Work. Quite the opposite: we want to respect the threshold.

In an image, grayscale describes how bright or dark a pixel is. Usually 0 is pure black, and 255 is pure white.

Agent Apps have a similar threshold.

Below it, the right answer is a one-off app, a skill, a local delivery, a place where you should avoid unnecessary complexity.

Above it, the work becomes building, evaluation, deployment, A/B testing, and production feedback. It needs a lifecycle.

Once you cross that line, the tools become scattered.

Developers have to stitch together point solutions: sandboxes, Eval Harnesses, deploy scripts, logs, permissions, context, UI, and functions where most of the real behavior still lives inside Prompt strings.

At that point, you are no longer using Codex or Claude Code to solve your own problem.

You are using them to build a production solution for your customer.

You live inside harnesses and dependencies. You open terminals, worktrees, or a new ADE, trying to keep the work moving.

That is when I kept asking myself: why is there no framework-agnostic "Supabase" for this?

Not to replace builders, but to remove repeated Agent Runtime hosting, deployment, isolation, and evaluation from every app.

Before cloud computing, building software felt like buying land, building a house, and running the property yourself.

You bought servers, switches, and storage. You put them into a machine room or IDC before you could talk about the application.

Agent App development is beginning the same journey.

We used to wrap tokens into LLM API Calls and treat them as the smallest compute unit.

Now we are wrapping tokens into requests against a Cloud Agent.

Local consumer demand represented by tools like Hermes or OpenClaw will continue. But more complex production demand will move toward Cloud Agents in Sandboxes.

It needs higher concurrency, longer-running jobs, stronger isolation, and background tasks that can be created, paused, resumed, evaluated, and deployed.

We are re-abstracting cloud machine resources into a Cloud Agent Session Lifecycle API that developers can call directly.

That is what we are building.

Not another Agent Demo.

Not another Prompt Wrapper.

It is a value judgment: once Agent Work crosses the threshold, it should be hosted, isolated, observed, and reused like a cloud resource.

We call it mosoo.

The first piece of that work is now open source: mosoo Agent Driver.

It is the driver layer we use to make OpenClaw, Hermes Agent, Claude Code, and Codex speak a compatible Agent Session API.

Originally published on Mosoo Blog. Mosoo is an open-source managed agent runtime for deploying sandboxed agents behind an API.

From responses to agents: the API becomes a runtime

Evanchen — Sat, 01 Aug 2026 08:24:45 +0000

By the GPT-5.6 era, the direction of OpenAI's API platform is difficult to miss. The model endpoint is no longer shaped only around generating the next piece of text. It can keep state, operate tools, compact a growing context, and coordinate parallel work.

One correction matters at the start: Chat Completions is not deprecated. OpenAI says it remains supported, while recommending the Responses API for new projects. The dividing line is architectural, not a shutdown date.

The important change is not a new endpoint. It is how much of the agent loop can now live inside the model runtime.

One flow instead of a text-shaped exchange

The Responses API works with typed items rather than treating every turn as another chat message. Messages, reasoning items, function calls, function outputs, and hosted-tool activity can participate in the same response flow.

That changes the integration model. A response can include an agentic loop in which the model uses multiple tools before returning its answer. The application still defines permissions and handles client-owned functions, but it no longer has to flatten every intermediate step into a transcript-shaped protocol.

State becomes a platform primitive

There are two server-side state patterns, and they solve different problems.

previous_response_id chains a new response to the previous one. It is the lightweight option for nearby turns: the client sends the new input instead of reconstructing and resending the complete history.

The Conversations API creates a durable object with its own ID. The same conversation can continue across sessions, devices, or background jobs. Its items can include messages, tool calls, tool outputs, and other structured conversation data.

The retention distinction is useful. Ordinary Response objects are stored for 30 days by default. Conversation objects and their items are not subject to that 30-day TTL. This is durable conversation state, not merely a connection-local cache.

It is also not an exposed log of private chain-of-thought. Applications should reason about the structured items the API returns, including supported reasoning summaries or encrypted items, rather than promise a replay of hidden internal reasoning.

As turns accumulate, useful context competes for a finite window. Source: OpenAI's conversation state guide.

WebSocket mode removes continuation overhead

Responses WebSocket mode keeps a persistent connection to wss://api.openai.com/v1/responses. Each continuation can send only new input items plus previous_response_id.

This is designed for long-running, tool-heavy loops such as coding or orchestration. OpenAI reports that rollouts with more than 20 tool calls have seen up to roughly 40% faster end-to-end execution. That is an observed upper bound, not a latency guarantee.

The connection can also be warmed with response.create and generate: false. A warmup prepares known tools, instructions, or custom messages without generating model output, then returns a response ID for the next turn to continue from.

WebSocket mode does not turn the API into an unlimited process. Connections have documented limits, and an application still needs reconnection, error recovery, and durable job ownership.

Compaction carries the useful state forward

Long conversations create a simple systems problem: more history means more tokens, more latency, and more competition inside the context window.

Server-side compaction can be enabled with context_management and compact_threshold. When the rendered token count crosses the threshold, the server emits an encrypted compaction item. That item carries key prior state and reasoning into the next window using fewer tokens.

The compaction item is opaque and not intended to be human-readable. It should not be described as a conventional summary or as a literal dump of a model's “latent understanding.” Its contract is narrower and more useful: preserve the state needed to continue while reducing context pressure.

For stateless input-array chaining, items before the latest compaction item can be dropped after the new window is assembled. When using previous_response_id, the service manages the chain and the client should not manually prune it.

Tools can be coordinated as a program

Programmatic Tool Calling lets the model write JavaScript that coordinates eligible tools. The program can use loops, conditions, parallel calls, and local transformations while keeping intermediate results inside the hosted execution step.

This is useful when control flow is predictable: query several sources, filter and rank the results, then return a smaller structure to the model. It can reduce unnecessary model decisions, repeated API continuations, and the movement of large intermediate payloads.

The runtime boundary is intentionally strict. Each program runs in a fresh isolated V8 environment with top-level await, but without Node.js, package installation, direct network access, a general-purpose filesystem, subprocesses, a console, or persistent JavaScript state. External effects are possible only through the tools enabled for that request.

Client-owned function calls still return to the application for execution. Programmatic Tool Calling compresses a class of orchestration; it does not move every integration into OpenAI's sandbox.

Multi-agent coordination reaches the API layer

The Responses Multi-agent feature is available in beta across GPT-5.6 models. A root agent can create subagents, give them bounded work, communicate with them, wait for results, and synthesize the final response.

HTTP and WebSocket expose the same capability, but their coordination behavior differs when client functions are involved.

With HTTP, blocked subagents resume after the active response completes and the application submits outstanding function outputs in a new request. Source: OpenAI's Multi-agent guide.

With WebSocket, each function output can be injected as soon as it is ready, so one subagent can resume while others continue. Source: OpenAI's Multi-agent guide.

The Agents SDK sits at a different level. It adds a reusable agent loop, sessions, guardrails, tracing, and two common ownership patterns: handoffs, where a specialist takes over the conversation, and agents-as-tools, where a manager retains control of the final answer.

The model runtime is not the whole product runtime

Together, these features move the API from a text-generation primitive toward an agent runtime substrate. State, context maintenance, tool execution, continuation, and delegation are becoming native platform concepts.

But the boundary still matters. The Responses API runs model-centric work. A production product may still need its own sandbox, files, credentials, authorization, durable job lifecycle, approvals, retries, observability, and customer-facing state.

That distinction is central to mosoo's view of the stack. Better model runtimes reduce the amount every team has to rebuild inside the inference loop. A managed agent runtime turns the remaining product-specific work into a deployable Agent with an environment, lifecycle, and API.

The paradigm shift is real, but it is not “one endpoint replaces the application.” It is a cleaner division of labor: the model platform owns more of the agent loop, while the product runtime owns the durable system around it.

Developer resources

Originally published on Mosoo Blog. Mosoo is an open-source managed agent runtime for deploying sandboxed agents behind an API.

From API to CLI + Skill: a new software development paradigm

Evanchen — Sat, 01 Aug 2026 08:10:09 +0000

While building mosoo, we originally followed a familiar sequence: build the API first, close the loop on the product's core capabilities, and only then create a CLI to make those capabilities easier for coding agents to use.

That sequence turned out to be backwards—or, at least, incomplete.

What we observed

Without a first-class CLI, coding agents usually tested individual API endpoints with curl, browser automation, or scripts written on the fly. Each approach created avoidable friction.

A raw curl response is often a large block of HTML or JSON containing fields that do not matter to the test at hand. The response itself does not explain field semantics, constraints, discovery, or the stable way to call the operation. Without sustained pressure from a CLI, SDK, or maintained tests, an API specification is also more likely to become incomplete, stale, or inconsistent with the implementation. The agent has to infer types, required fields, and constraints from source code, errors, and surrounding context. That consumes more tokens and more time.
Browser automation is expensive in tokens, slow, prone to stalls, and awkward for the person waiting on it.
Temporary test scripts multiply quickly. They become long, structurally inconsistent, and difficult to maintain. Reading them consumes yet more context.

These methods are especially weak for orchestrating integration tests. The agent repeatedly produces piles of nearly unreadable scripts; once the test itself is unreadable, its result becomes difficult to explain or trust.

After getting used to vibe coding, someone may still glance at the business logic. Test code often receives even less attention. Code nobody reads has almost no value.

This problem followed mosoo throughout development. The turning point came when we used Lathe, an open-source API-to-CLI generator, to generate a complete CLI for mosoo.

What Lathe provides

Lathe is designed for teams whose APIs must serve both people and AI agents. It turns Swagger 2.0, OpenAPI 3, or Protobuf APIs with google.api.http annotations into a production-grade Cobra CLI.

The generated CLI includes a machine-readable command catalog, intent search, per-command detail JSON, authentication metadata, request-body builders, structured output, and a repository-local skills/<cli-name>/ directory.

That combination matters. The result is not merely a set of shell commands. It is a discoverable interface an agent can inspect before deciding what to run.

A new discovery—and a new problem

After generating the CLI, I built skills, workflows, and instructions around it. End-to-end testing and load testing in mosoo became dramatically simpler and faster.

I could sketch a batch of cases and hand them to a coding agent. The agent could implement the cases, run them, and collect the results. Skills, the CLI, and prompt-based workflows supported the entire path.

More importantly, I could readily believe—or challenge—the agent's conclusion because the testing process was readable and explainable. It also felt far less token-intensive than the previous approach, although we did not run a controlled benchmark.

But generation alone did not solve everything.

Lathe converts every API in a project into CLI commands and generates a skill around that surface. It does not know which APIs are central to the product, which should remain internal, which operations form a complete business workflow, or when a particular command should be used.

The first generated CLI was therefore difficult for an agent to use. It did not know which command to choose or when not to use one. At the time, the generated catalog exposed 127 commands, including hidden commands. The volume of operations also created naming and governance problems.

We had to apply our understanding of mosoo's business domain. We reorganized the skill, exercised a large set of CLI-driven cases, and incorporated agent feedback. From generating the first mosoo CLI to making it genuinely usable by coding agents took about a month of intermittent work.

What if the CLI started on day one?

What would happen if, from the first API on day one, we:

generated its CLI surface;
deliberately selected which APIs should and should not become commands;
identified which commands compose into workflows;
documented the business situations in which each command applies; and
wrote the corresponding SKILL.md by hand?

The mosoo CLI would likely have been smaller and more agent-friendly. Command names could have been shorter and easier for people to read. The overall development loop might have moved faster and consumed less context.

Why did we not build the CLI first?

By June, I was already advocating for a CLI even before the API was complete. Dogfooding cases without one had become painful. The first mosoo CLI did not ship until July, two weeks after Lathe was introduced to the team.

Two assumptions held us back.

First, we had not adapted to how software is consumed in the coding-agent era: less dependence on UI, and a CLI-first operational surface. During the first two months, API development was driven largely through mosoo's frontend. We judged the system with our eyes instead of its inputs and outputs. That made it easy to spend too much attention on naming debates and visual polish while leaving less attention for the product's underlying behavior.

Second, we assumed introducing a CLI early would add complexity. We imagined that every API change would require manual regeneration and distribution. With a generator and a stable workflow, however, that maintenance cost approaches zero. The CLI instead creates healthy pressure to keep the API specification accurate, which also improves the API documentation.

The development loop

My current view is that software development in the coding-agent era should follow this loop:

Develop or modify an API.
Update or export its API specification, such as OpenAPI or Swagger.
Generate or refresh the CLI, command catalog, and skill.
Validate every API operation through the CLI.
Compose CLI commands into workflows.
Run integration and end-to-end tests.
When a problem appears, return to the API, generated interface, or workflow layer that owns it.

Then repeat.

The important part is for this loop to become an invisible project contract. A user should not have to remind a coding agent to generate the CLI or test through it.

That suggests a project template similar to what an IDE offers when creating a new project—but designed for coding agents. It would include CLI and skill generation from the beginning, along with an AGENTS.md that makes the workflow explicit.

I have not yet surveyed whether a complete template like this already exists. Lathe may be close to providing one.

Originally published on Mosoo Blog. Mosoo is an open-source managed agent runtime for deploying sandboxed agents behind an API.

An agent's state is not its process

Evanchen — Sat, 01 Aug 2026 08:08:22 +0000

Two recent discussions about cloud agents exposed a real architectural disagreement.

The first discussion offered two choices: run agent loops centrally and send only tool calls to sandboxes, or give every user a complete isolated agent runtime. Its replies did not converge. Some favored centralized control; others argued that coding harnesses such as Codex and Claude Code already bind the loop, tools, and workspace tightly enough that a complete runtime is the more natural boundary.

The second discussion moved the question forward: perhaps a system should persist the data model needed for interaction, not the agent process itself. Its author later acknowledged that existing coding harnesses are difficult to split cleanly into a central loop and sandboxed tools. The post's “30-second cold start” claim has no public reproducible measurement conditions, so we do not treat it as evidence here.

These threads are more useful as a question set than as market consensus. Our answer is:

Define user-visible continuity and acceptable loss first. Then decide where the loop and sandbox belong. The deployment unit should follow the durability contract, not define it.

Draw the failure boundary before choosing a deployment unit

“Agent state” contains at least three things with very different lifetimes:

Product facts: the agent configuration version, Session and Run state, accepted events, explicit uploads, and produced artifacts.
Control state: authorization, scheduling, command delivery, event acknowledgement, and the runtime currently serving a subject.
Execution state: the provider-native session, working directory, caches, login state, temporary files, and live processes.

A useful boundary is not “cloud versus local.” It is “what remains part of the product promise after a process disappears.” The diagram describes mosoo's current responsibility split; it is not a multi-cloud or zero-loss claim.

If the execution environment on the right disappears, can the durable side still explain what the user saw, what work completed, and which files should exist? If not, “recoverable” only means that a process has not died yet. The system does not have recovery semantics.

How mosoo draws the boundary

mosoo does not implement another universal model planner. When it creates a Session, it freezes an execution snapshot: the Agent's prompt, model, runtime, tools, Skills, MCP bindings, and Environment revision are bound to that Session. This is a traceable behavior configuration, not a full machine image.

The control plane manages execution through a narrow set of operations such as prepare, dispatch, terminal, reset, recreate, and stop. The current code has one execution adapter, Cloudflare Sandbox, so we do not describe this as a completed multi-cloud abstraction.

At boot, the runtime writes a private payload to a one-time file. The Driver reads and removes it, then actively dials an authenticated WebSocket to the control plane. The implication is simple: a sandbox may execute work without becoming the sole source of truth for credentials, Session ownership, or durable facts. The architecture document makes this chain explicit.

Inside the sandbox, Agent Driver keeps each provider's native loop. Its current registry integrates OpenAI app-server, Claude Agent SDK, and ACP. It normalizes start, input, cancel, and stop, plus host ports for events, permissions, MCP, Skills, and files; it does not pretend the provider runtimes are one internal implementation. Capability differences remain explicit.

That boundary accommodates both sides of the original debate. A coding harness can remain whole inside the sandbox, while product control, identity, and durable facts do not have to be trapped in the same process.

Pet and Cattle are continuity contracts

mosoo does not assume that every Agent needs the same runtime lifetime. kind becomes two observable policies:

	Pet	Cattle
Runtime subject	Stable `agent:{agentId}`	Session-scoped `session:{sessionId}`
After a Run becomes terminal	Not closed only because the Run ended	Sandbox is closed and recycled immediately
Preserved across rebuild	Only `/workspace/memory` and eligible Session workspaces	No checkpoint
Not promised	Login state, caches, provider-native state, and other container files after rebuild	Temporary files, caches, login state, and native runtime state

These are not naming preferences. They are runtime policies in code. The complete persistence matrix is also published in the architecture document.

“Continue the same Session” therefore does not have to mean “revive the same process.” A later Cattle Run gets a fresh sandbox; product history remains readable, but the old workspace and provider-native state are not presented as if they still existed. Pet offers stronger continuity, but it is still a bounded checkpoint policy rather than an immortal container.

Reaching a WebSocket is not becoming a fact

Streaming and durability are another pair of concepts that are often collapsed.

mosoo's event ingress filters replays, projects and persists canonical events, delivers committed events to viewers, and only then returns an accepted receipt. The source explains why: acknowledging fragments buffered only inside a hibernatable process could confirm text that a fresh instance cannot reconstruct.

The current Agent Driver main goes further by separating lossless and best-effort events. Lossless events retain source IDs, drain partial receipts, and retry unconfirmed work; best-effort events may be dropped on transport or receipt failure. The queue implements the distinction explicitly. OpenAI text deltas are marked best-effort; a final item snapshot arbitrates the complete message.

One version boundary matters: the mosoo commit linked in this article still pins an earlier Driver revision. The new queue semantics are the current implementation direction on Agent Driver main, not a blanket promise that every stream in an existing mosoo deployment is lossless. The more accurate principle is:

Incremental streams serve the experience. Persisted events and terminal snapshots serve the facts.

The market needs falsifiable evidence

“Central loop,” “complete runtime,” and “durable agent” can all become labels. Publishing evidence that others can reproduce—and disprove when it fails—contributes more than choosing a camp.

Capability being claimed	Minimum evidence
The Agent can resume	Kill the connection, Driver, and sandbox separately; record which messages, files, and native sessions return and which do not
Startup is fast enough	Publish the workload, image, region, warming and pooling conditions, and P50/P95/P99 cold and warm distributions
Events are not duplicated or lost	Replay the same source ID after disconnect; verify deduplication, partial acknowledgement, and the persistence boundary
Sandbox isolation is effective	Name the identity, credential, network, file, and tenant boundaries, then publish failure tests instead of only a container-shaped API
Cancellation completed	State which cooperation stopped and which tool side effects cannot be rolled back

mosoo also has gaps worth stating plainly: there is only one execution adapter; automatic crash requeue is unfinished; some network policy is saved intent rather than enforced policy; Cattle does not persist native resume state. Publishing those non-goals next to implementation links helps other teams judge fit better than calling a direction “mainstream.”

A long-term judgment

We treat runtime state as a cache until the product explicitly promises continuity. We separate semantic resume from process resume. And we see per-user runtimes and sandbox-as-tool as product modes, not mutually exclusive beliefs.

A durable abstraction is not one that keeps a process alive for as long as possible. It is one that can still answer three questions after that process disappears: what happened, what the user still owns, and where the next execution begins.

References

Originally published on Mosoo Blog. Mosoo is an open-source managed agent runtime for deploying sandboxed agents behind an API.

The Model Is Streaming. Why Is the Text Still Jumping?

Evanchen — Fri, 31 Jul 2026 10:45:58 +0000

This post shares what we learned while improving Mosoo's streaming output. The model already streams native deltas; the Web UI's job is to turn bursty delivery into perceptually continuous text without adding enough work to erase the benefit.

The model may be streaming, but the text on screen does not necessarily look like it is.

A model can keep returning native deltas, yet those deltas pass through a provider, an Agent Runtime, event buffering, and WebSocket delivery before they reach the browser. By then, the browser often receives them in batches. If the Web UI inserts each entire batch into React as soon as it arrives, users see a repeating pattern: nothing, then a jump of text, then nothing again.

That does not mean the model stopped generating. It does not necessarily mean the network slowed down either. The problem is that we treated two different clocks as one.

Streaming output has two clocks: when events arrive, and when text enters the next screen paint.

`requestAnimationFrame` is not the same as smoothing

mosoo's server does not send a separate WebSocket message for every tiny delta. Viewer events are compressed and merged for up to 150ms. The buffer flushes early when it reaches 4KB or 64 events, and also for the first delta or a terminal Run event. Those limits live directly in the delivery buffer, while the fast paths for the first delta and terminal events have their own explicit conditions.

This is a necessary systems tradeoff. Batching reduces message count, serialization work, and downstream state updates. The cost is that the browser's input rhythm no longer matches the model's generation rhythm.

The old implementation already used requestAnimationFrame to combine rendering work, but it delivered the entire queued batch on the next frame. rAF answers when to commit. It does not answer how much to commit in that frame. If one WebSocket message already contains roughly 150ms of output, delivering all of it on the next frame still produces a jump.

The control variable is pending backlog, not a fixed typing speed

The obvious solution is a typewriter: reveal one character every few milliseconds. A fixed speed, however, cannot adapt to slow models, fast models, short tails, and sudden large batches at the same time.

Too slow, and the model finishes while the user is still watching text from seconds ago.
Too fast, and transport batches remain visible as jumps.
One timer per character also creates a large number of callbacks and state updates.

mosoo uses a different control variable: the number of graphemes already received but not yet rendered.

pending = received - rendered
rate = clamp(pending / 0.25s, 20, 800)
budget += rate * elapsedSeconds
emit = floor(budget)

The larger the backlog, the faster the next frame catches up. The smaller the backlog, the gentler the pace. A time constant of τ = 250ms keeps a transport batch of roughly 150ms in flight until the next batch is likely to arrive, turning adjacent steps into a continuous stream. The 20–800 graphemes-per-second bounds prevent a short tail from dragging on forever and prevent the animation from becoming too fast to read.

The browser does not replay every model token. It uses a second clock to follow the first. Each frame's budget is driven by backlog, not by a fixed typing speed.

The budget uses the actual elapsed time Δt instead of assuming that every frame lasts exactly 16ms. A 60Hz display, a 120Hz display, and a throttled page therefore produce similar visible progress over the same wall-clock interval. A budget smaller than one grapheme is not discarded; its fractional remainder carries into the next frame. The complete budget calculation and queue slicing live in one Scheduler.

The unit of slicing is a grapheme, not a UTF-16 index

Slicing by JavaScript string index can split a surrogate pair, combining character, or ZWJ emoji. For a moment, the UI may render � or half an emoji.

When an event enters the queue, mosoo uses Intl.Segmenter to split it into grapheme clusters in advance, with code-point iteration as the fallback. That work happens once, and the per-frame budget reuses the result. This preserves text correctness without rescanning the same string on every frame.

Smoothing must know when to stop

A Scheduler that only knows how to “show text slowly” is incomplete. Animation must yield to event semantics.

When the queue contains Message End, Reasoning End, a terminal Run event, or a State / Messages Snapshot after reconnection, mosoo immediately delivers the preceding backlog. The server has already established that the segment is complete, so there is no reason to keep playing stale animation. These events are explicit pacing barriers in the code.

Likewise, when the backlog exceeds 4,096 graphemes, the Scheduler delivers the whole batch immediately. Continuing at the maximum animation rate could still leave the screen seconds behind the real state. Stopping the polish under overload is part of the performance strategy.

Smoothing exists only while generation is active and backlog is under control. Correctness, terminal state, and freshness take priority.

Several other boundaries matter:

Every event stays in strict FIFO order. A later tool or state event cannot overtake text that is still being revealed.
At most 512 events are delivered in one frame, preventing a pathological event storm from creating one enormous React commit.
When a hidden page pauses requestAnimationFrame, a 50ms timer continues draining the queue.
When the socket closes, the active Session calls flushNow. Queues for inactive Sessions are cleared so content cannot leak into another Session.

After a WebSocket event arrives, the Scheduler submits at most one batch to Live State per frame. Closing the connection triggers an explicit flush. That integration boundary stays inside the Session Stream Socket.

Low overhead is not a magic number

This change adds no animation library and creates no timer per character. It reuses the browser's frame clock and handles budgeting, slicing, and batched state updates in one queue:

Graphemes are segmented once, when they enter the queue.
Each frame computes an integer budget from actual elapsed time.
A frame triggers at most one batched state update.
Only user-visible text deltas are paced; structural events do not receive a character-by-character animation.
Terminal state and excessive backlog both have direct exit paths.

These are structural constraints for keeping overhead low, not an unmeasured performance promise. PR #450 focuses its verification on timing semantics: controlled clocks cover 60Hz / 120Hz consistency, emoji boundaries, terminal flushing, reconnection snapshots, strict ordering, hidden-page fallback, and excessive backlog. Each case is visible in the test file. We did not run production CPU or long-task benchmarks for this change, so we do not turn “smoother” into an unsupported claim that it is “measurably faster.”

A reusable principle

If you are building a Web UI on top of native model output, start with four rules:

Let the first delta bypass transport buffering to protect time to first text.
During generation, adjust the per-frame rate from backlog instead of using a fixed typing speed.
Flush terminal events and snapshots immediately; explicitly flush or clear the queue when the connection closes or the active Session changes.
Stop animating when backlog escapes control. Freshness matters more than smoothness.

The transport layer reduces system overhead. The rendering layer maintains perceptual continuity. Event semantics decide when both must yield.

That is the core of mosoo PR #450: we did not change how the model produces output or fabricate more tokens. We gave the browser a bounded display clock, with explicit exit paths, that faithfully catches up with the model's native stream.

About Mosoo

Mosoo is an open-source, Cloudflare-native agent runtime for Codex, Claude Agent SDK, and OpenCode—with API endpoints, isolated sandboxes, durable Threads, and inspectable Runs.

Originally published on the Mosoo engineering blog.

DEV Community: Evanchen

Two kinds of agents: Pet and Cattle

Where these terms came from

Type one: Pet, an agent you cultivate

Type two: Cattle, an agent pipeline that replaces a workflow

The same support agent can be two entirely different products

Why mosoo implements both Agent Types

This will become a dividing line across the agent industry

How ghfind turns a Mosoo Agent into a project evaluation feature

What is ghfind?

What does Mosoo do here?

The boundary between Agent and application

The current integration cost

The reusable lesson

From model calls to agent tasks

Local agents proved the runtime

Productizing agents exposes the runtime gap

The unit of work is a task

A managed agent runtime, exposed as an API

From local prototype to product

The journey begins with an Imagine If.

From responses to agents: the API becomes a runtime

One flow instead of a text-shaped exchange

State becomes a platform primitive

WebSocket mode removes continuation overhead

Compaction carries the useful state forward

Tools can be coordinated as a program

Multi-agent coordination reaches the API layer

The model runtime is not the whole product runtime

Developer resources

From API to CLI + Skill: a new software development paradigm

What we observed

What Lathe provides

A new discovery—and a new problem

What if the CLI started on day one?

Why did we not build the CLI first?

The development loop

An agent's state is not its process

Draw the failure boundary before choosing a deployment unit

How mosoo draws the boundary

Pet and Cattle are continuity contracts

Reaching a WebSocket is not becoming a fact

The market needs falsifiable evidence

A long-term judgment

References

The Model Is Streaming. Why Is the Text Still Jumping?

requestAnimationFrame is not the same as smoothing

The control variable is pending backlog, not a fixed typing speed

The unit of slicing is a grapheme, not a UTF-16 index

Smoothing must know when to stop

Low overhead is not a magic number

A reusable principle

About Mosoo

`requestAnimationFrame` is not the same as smoothing