CopilotKit

The daily trait is shared state. The agent and your interface read the same object, so a step it takes updates the screen without you writing a polling loop or inventing an event schema. Anyone who has built a chat surface over a long-running task knows how much plumbing that removes, and it is the reason to reach for this rather than rolling your own.

Skip it if your product is a text box over a fast call, because then it is a dependency for nothing. Pick Dify if you want the agent, the retrieval and the interface bought together.

The coupling is worth naming. Connections to the agent frameworks it lists run over a protocol this team wrote, which is presented as an open standard and is currently a house format with adopters rather than a specification with competing implementations. If the sponsor's priorities move, the standard moves, and every framework integration that depends on it moves too.

Treat the protocol as a vendor interface until a second implementation exists. What it does right: human approval is a first-class step in the run rather than something each application reinvents at the last minute.

The consequential design decision is that a run can render components mid-execution. The model's output is therefore not only prose to be read but a choice of interface element, and a wrong choice produces something that looks authoritative rather than something that reads oddly. Errors become harder to notice, not easier.

The compensating property is separation of concerns: this layer does not execute the agent, it displays one, so the reasoning stays wherever it lives and this stays replaceable. No evaluation of selection accuracy is published, which is the number a careful adopter would want.

Interface layers rarely accumulate this kind of following, and the position is strategically attractive: whoever owns the surface users touch sits between every agent framework and every customer, which is a place other people's competition flows through rather than around.

Conversion is the open question. Developers install the free library and self-host it, so the paid tier must sell something the library cannot do, and that boundary has to be drawn without alienating the audience that produced the distribution. Likely acquirer: a front-end platform or a framework vendor buying the last mile. Position: long the position, watch the conversion rate.

Finance has nothing to approve. Security does. Code that reaches the browser of every customer gets a supply-chain review, a version pin and a place in our dependency monitoring, which is a standing cost measured in review hours rather than dollars, and one my platform team has to accept before the first team adopts it.

The Slack and Teams channels are the part my internal-tools group would actually use, because that is where our people already ask questions. Onboarding a React engineer is a day. Approved with conditions: pinned versions, a named owner, and no customer-facing use before an audit.

One command scaffolds it, the licence is MIT, and the hosted service is optional rather than load-bearing, which is the test I apply to anything with a company attached. I ran it against my own backend with no account and nothing broke.

Reaching past React into Vue and React Native matters to me because it means the abstraction was designed rather than extracted from one application. There is no MCP here, which for a rendering layer I can live with, since the tools belong to the agent one level down. This is a library I would keep after a fork, and that is the whole review.