Everagentic
An agent platform where the agents are data. The prompt, the tools, the skills and the model behind an agent are all edited in an admin UI, and changes take effect on the next request instead of the next deploy.
Most agent work ends up as code. The prompt is a string in a Python file and the tools are a list in the same file, so changing how an agent answers means a pull request, a review, and a deploy. That's fine while the person writing the prompt can deploy. It stops working the moment the domain expert isn't an engineer, and in any serious application the domain expert isn't an engineer.
- 01Agents defined as data, not code
- 02Edited in a UI, live on the next request
- 03Routers hand work to specialists
- 04Journeys run a fixed set of steps, in parallel
- 05A failed step is a labelled gap, not a dead run
- 06Provider-agnostic across Claude, GPT, and Gemini
The pieces
A handful of primitives, and everything else is built from them.
- Agent — a prompt, context, and its capabilities
- Router — reads a question, picks the agent that owns it
- Model — prose only, used for tone and house style
- Journey — steps in a fixed order, fanned out where they can be
- Template — turns the output into the finished artifact
- Hook — code that runs after an agent finishes
Why a journey instead of a router
A router asks a model who should answer. A journey doesn't ask. That matters when something has to cover a fixed set: if a report needs five specialist reads, a model deciding who participates is a report that's quietly missing a section. A journey runs all five every time, and a step that fails becomes a labelled gap in the output rather than an absence nobody notices.
Steps in the same wave can't see each other's output, which is deliberate. Five specialists asked the same question independently is a panel. Five specialists each reading the previous one's answer is a game of telephone.