about

The hard part starts after the first tool call.

Psych exists so teams can build agents and workflows without writing an execution engine for every product.

Why it exists

Getting a model to call a tool is the first step. Production work also has to survive a stopped process, wait for a person, keep tenants apart, and explain what the run costs.

Every team building on agents writes that layer. This is that layer, written once, with the reasoning recorded next to it.

Who it is for

A company with a service, a database, an identity system and a frontend already. They want their users to create agents, run them, and see what happened. They do not want to write an agent loop, a durable execution engine, a token accounting system or an MCP client pool.

They would also not thank a dependency that arrived with its own users, its own tables and its own web server.

how it is shaped

A library, not a framework.

You call Psych; it calls back only through ports you supplied: your store, your model client, your sandbox, your telemetry. It never runs your agents for you, because the moment it did you would have a second service to deploy, version and page someone about.

Each design decision is written down with the failure it prevents: why a report is computed from the log rather than stored, why a contradictory log fails loudly, why a lease and a deadline are separate mechanisms.

the name and the mark

Psych, and the trident.

The name is short for psyche, and the mark started from the shape of the Greek letter psi. That is where the idea came from rather than a claim about what the word means: the point was cognition and the machinery under it, not the clinic.

Drawn as a system glyph, three prongs meet one stem. Read them as the model, the tools and the store you supply, with the record log they fold into running up the middle. Everything you read back comes up that stem.

The Psych Runtime mark: psi drawn as a trident

who maintains it

In the open, under Apache-2.0.

Psych Runtime is developed by psych-systems in a single public repository: the library, the playground application, this site and the design document all live in it. Issues and pull requests are the whole process, and the contribution guide says what a change has to pass before it lands.

It is pre-alpha at 0.x, and the public API still changes between minor releases. Names scheduled for removal ship at least one minor release warning first, and every breaking change is written into the changelog by the commit that makes it true.