Griptape

The daily trait is that you choose a structure first. One task is an agent, an ordered series is a pipeline, and parallel work is a workflow, so the decision about how the job runs is made once and made explicitly rather than emerging from whatever you wrote last. That saves the refactor most people hit in month two.

Pick it if you like a framework with opinions. Pick Pydantic AI when the vocabulary feels like overhead, because three structures and three kinds of memory is a lot to hold before the first useful line runs.

The isolation is the problem. Tools written for this framework work only here, and the growing population of servers everyone else can consume is unreachable without a bespoke adapter per server. That gap widens without anyone deciding it should, and the maintenance falls on the adopter rather than the maintainer.

Count the tools you would have to rewrite before committing. What it does right: an evaluation engine ships with the framework, so measuring output quality is a first-class activity rather than a thing users assemble from other libraries afterwards.

The decomposition is principled. Three structures correspond to three execution shapes rather than to three marketing categories, which means the choice a developer makes at design time has a direct operational meaning. The memory split is the more unusual contribution: separating conversational history from task-scoped state and from metadata prevents the single undifferentiated transcript most frameworks accumulate.

Provider concerns sit behind a driver layer, so the abstraction boundary is consistent. Verification is left to the user's own tests, and no benchmark accompanies any of it.

When a company ships a second product in a different form factor, the first one has usually stopped being the plan. A node-based desktop application reaches a different buyer than a Python library does, and building it is a decision about where the revenue might come from, made by people who already tried the other thing.

For an adopter that means the library's roadmap now competes internally for attention. Moat: none evident. Likely path: the desktop product carries the company, or an acqui-hire ends the question. Position: use the library, assume it is maintained rather than developed.

Cost is engineer time, and it runs headless, so it fits pipelines we already operate and produces artefacts we can schedule and monitor. The concern is the bus factor on our side rather than theirs: with a user base this size, whoever adopts it becomes the only person here who understands it, and that person eventually leaves.

There is no console and therefore no access control, and no vendor to escalate to. Onboarding a Python engineer is a week, mostly spent on the structures. Approved with conditions: two engineers must learn it, not one, and the choice gets revisited in two quarters.

The driver layer is the part I respect. Model, embedding, search and observability providers are all behind the same kind of interface, so replacing any of them is a class rather than a patch, and I wrote one in an afternoon without reading much of the surrounding code.

Local inference is not in the documented model support, which for a framework this configurable is a strange gap, since the driver interface is exactly what makes it easy to add. Apache-2.0 means my version stays mine. So I have a driver nobody asked for and a framework that made writing it pleasant.