Yang: the software factory behind Composio's toolkits

Somewhere right now, a SaaS company is renaming a field in an API response. Nobody will write a changelog entry for it. The docs will keep showing the old name for a few weeks, and the next agent that calls that endpoint through Composio is going to get back something it didn't expect.

That's a normal Tuesday for us. Composio gives agents tools for hundreds of third-party APIs, and every one of those APIs changes on its own schedule. An agent that calls a broken tool might fail loudly. Worse, it might succeed at the wrong thing and keep going.

Yang is the system that keeps those toolkits working. Coding agents build and repair toolkits, review bots check the code, production telemetry decides whether a fix held, and a human approves every merge. Inside the company people call it Yang, the toolkit builder, or just "the bot." I've started calling it a software factory, because that's what it is.

Why toolkits are hard to keep working

From the outside, an integration looks like a solved problem. Read the docs, map the endpoints, write some tests, ship it. Most developers have written at least one of these and walked away feeling done. Doing it a few hundred times, and keeping every one of them correct while the providers keep moving, is a very different job.

The provider side

Provider docs are the first thing you learn not to trust. Some are wrong from day one, and you only find out by calling the endpoint. Others were accurate when you read them and stale by Friday, because the provider shipped a change and nobody updated the page.

Changelogs have the same problem. Plenty of API changes never get an entry. Fields get renamed, defaults change, and endpoints get deprecated with no warning beyond the day they start returning errors.

Rate limits are worse. Many providers don't document them at all, or document limits that don't match what production enforces. You learn the real numbers when traffic arrives and a burst of calls starts coming back as 429s.

The tenant side

The same toolkit behaves differently for different customers. Permission scopes vary by tenant, so a call that works in one workspace returns a 403 in another because an admin restricted a scope years ago. Large providers have more than 100 scopes to get wrong.

Data varies too. A field that's always populated in a test account might be empty, enormous, or in a different locale for someone else. None of this shows up in a unit test.

The human side

Proving a toolkit works means calling its endpoints against a real account. For a provider with a thousand endpoints, that's a thousand endpoints called with the right scopes, returning real data, checked by someone who knows what correct looks like. Someone has to provision those accounts and keep them working. Someone has to decide which failures matter.

Every broken toolkit is also ops load. When one breaks at 2am, someone has to figure out whether the problem is the provider, the tenant, or us, then write a fix and get it reviewed. Multiply that by hundreds of toolkits and you get a team whose whole job is keeping the lights on.

Yang exists to absorb that work. The rest of this post walks through how it does it.

What Yang is

Yang is a control plane for coding agents. It decides when an agent session starts, what the session is trying to accomplish, when its work counts as done, and what happens after its PR ships. The agents themselves run OpenCode inside ephemeral sandboxes.

Three loops feed it work:

• The build loop creates a full toolkit from a provider's documentation.
• The fixer loop turns production failures into small repair PRs.
• The usage loop watches which endpoints agents call directly and drafts the actions a toolkit is missing.

All three share the same machinery for defining done, surviving long sessions, getting code reviewed, and verifying results in production.

Defining "done"

Every Yang session follows a blueprint with a strict rubric for each stage. The agent researches the provider's documentation, reviews earlier attempts at the same toolkit, and consolidates what it finds into a report. The agent that builds the toolkit works from that report. Then Yang tests every endpoint against a real account.

Each stage has explicit passing criteria. "Make it work" is too vague to be a spec, and an agent given a vague spec will happily decide it's finished.

The blueprint doesn't script every move, though. OpenCode follows the workflow and starts 10 to 15 subagents for research and review. It can dig through a provider's changelog or chase any other lead that looks useful. The rubric only controls when a stage counts as complete.

Sessions that survive failure

Big toolkits take hours. With a thousand endpoints and more than 100 scopes, a Yang session regularly runs for six hours. The agent writes research and intermediate results to disk, reloads them when it needs them, and gets scheduled reminders of the plan so it doesn't drift.

Six hours is plenty of time for something to go wrong. Sandboxes get preempted. Model providers have outages.

So Yang keeps nothing important in the sandbox. Each session is a durable conversation with its own identity in Postgres. When a session goes idle, Yang snapshots the sandbox filesystem and destroys the sandbox. The session can wake again for up to 29 days, and its timeline stays available permanently.

If you're building something like this, I'd start here. Every other loop depends on sessions that can die and come back.

Bots review first

A 5,000-line toolkit PR is slow for a person to review, and the first round of comments usually covers things a bot could catch.

So Yang opens a PR and waits for Cursor's BugBot, Greptile, and Parameter AI. When a review comment arrives, the session wakes up, reads it, pushes a fix, and goes back to sleep. A person sees the PR only after the review bots have converged and every check is green.

In a recent week, 85% of Yang's PRs merged without a human requesting changes. Only 10% needed two or more rounds of human feedback.

A PR is a claim

A green CI run shows that a change is internally consistent. It can't tell you about provider rate limits, tenant data, or what happens under real traffic.

So Yang treats every PR as a claim that something is fixed. CI checks the implementation. Once the commit reaches production, Yang watches that toolkit's telemetry for seven days. If the failure doesn't come back, the claim holds. If it does, Yang starts another repair cycle.

A human approves every merge to main. Repository permissions enforce that, so it never depends on the agent following an instruction.

Turning production failures into repairs

Composio records telemetry from toolkit calls in ClickHouse. A sensor strips privacy-restricted fields and projects the remaining evidence into Yang. Typed control loops group related failures and decide which ones deserve a repair.

Yang quarantines provider-controlled text, including error bodies, before it reaches any agent that can write code. A third-party error message is untrusted input, and it should never get the chance to give an agent instructions.

The fixer runs on a schedule. It opens a session, makes the smallest change that addresses the failure, opens a PR, and sends it through the same review loop as everything else.

More than 900 fixer PRs have merged this way. In that same week, the median fix was 67 lines, and every one needed nothing from a human beyond approval.

Letting usage decide what to build

Composio's proxy sees API calls that agents make outside an existing toolkit. When agents keep calling an endpoint the toolkit doesn't cover, that's a strong signal the toolkit is missing an action.

Yang drafts that action, tests it, and opens a PR. Nobody has to file a ticket.

Thirty-two of these PRs merged that week. Their median size was about 1,100 lines, and 69% needed only human approval.

This is the loop I like most. The roadmap for each toolkit comes from what agents actually call.

Correctness lives in the system

You could try to make an agent like this reliable with instructions:

• Be skeptical of error messages.
• Make sure the problem is actually fixed.
• Don't merge without review.
• Save your work.

Yang doesn't depend on the agent following any of those. Raw provider errors never reach a write-capable agent. A separate process decides whether a production fix succeeded. Repository permissions keep the agent from merging. Session state lives in Postgres, outside the sandbox.

Every item on that list is enforced by how the system is wired, so the agent can't break the rule even if it ignores the instruction. A prompt tells an agent what it should do. The system decides what it can do.

Lights-out factories work the same way. The robot arms get the attention, but what makes an automated plant safe to run overnight is the interlocks and light curtains that stop the machine before it does something dangerous. Yang's interlocks are boring on purpose, and they're the reason the team is comfortable letting it run while everyone sleeps.

What it adds up to

Yang supports every Composio toolkit. It ran 726 sandboxes in the last 24 hours and about 5,000 in the last week alone.

Composio users never see any of this. They call a tool. When the tool breaks, Yang has often noticed already, and a repair PR is waiting for review before anyone files a report.

Gergely Orosz recently wrote about OpenAI's internal software factory, and its shape is close to Yang's. Neither team copied the other. Agents that ship production code run into the same constraints, and those constraints end up drawing the architecture.

If you're building agents that depend on dozens or hundreds of third-party APIs, you'll hit the problems at the top of this post whether you plan for them or not. Explicit completion criteria, sessions that survive failure, bots in front of human review, and production telemetry as the final test are where I'd start.