Overview

Stable

How Pimsy turns raw model reasoning into durable, domain-specific competence across engineering, planning and financial work.

A capability is a bounded domain of work that Pimsy is expected to perform to a professional standard — not a prompt template, but a package of domain grounding, tool bindings, verification rules and escalation policy that together make an agent competent in a specific field.

A base model can produce plausible output in almost any domain. Plausibility is not competence. A capability closes the gap between the two by attaching the three things a raw model lacks: a persistent model of the domain’s state, tools that act on that state rather than describing it, and a definition of what "correct" means that can be checked before the work is presented. Everything on this page is built on the same runtime primitives documented under Agent Runtime; capabilities are how those primitives are specialised.

Anatomy of a capability#

Facet	What it supplies	Why the raw model needs it
Grounding	A structured model of the domain the agent operates on	The model reasons over its context, not over live state it cannot see
Tools	Bound actions with schemas, permissions and side-effect classes	Reasoning about an action is not the same as performing it safely
Verification	Domain-specific checks that must pass before output is surfaced	A confident answer and a correct answer are indistinguishable from text alone
Escalation	The threshold at which the agent must hand control to a human	Some decisions are not the agent’s to make regardless of confidence

The current capability set#

CodingReading, writing and reviewing software against a real repository model rather than a snippet in context.PlanningDecomposing an ambiguous objective into an ordered, revisable plan the agent executes against.FinanceManaging money, portfolios and market activity under strict verification and human-authority rules.

Why capabilities are bounded#

It is tempting to treat an agent as a single general worker and let the model decide what any request requires. That design fails in exactly the places that matter: the model under-scopes a risky action because nothing forced it to recognise the domain it had entered. Bounding a capability means the runtime, not the model, decides that a request touching money is subject to financial verification, and that a request touching a protected branch is subject to review. The model proposes; the capability boundary is what makes the proposal safe to act on.

Last updated 2026-09-02