Specifications for the agents we build: what each one is for, what it needs as input, what it produces, how the work flows, and how it is put together.
The specification for a read-only assistant over ERP data: plain-language questions answered from a curated query surface, run under the asking user's own permissions, with the filters shown beside every figure.
High complexity · 5 min read
The specification for a research agent that answers one written business question from allowlisted sources, carries a citation on every claim, and is allowed to report that something is not established.
Medium complexity · 5 min read
The specification for a grounded support agent: it answers from your documentation, cites what it used, refuses what it cannot support, and hands off with the whole conversation attached.
Medium complexity · 4 min read
The specification for an inbound sales development agent: what it is for, what it needs, what it produces, how the work flows, and the approval gate it can never route around.
High complexity · 4 min read
An agent is only useful if you can say precisely what it is allowed to do. Every page in this category is written as a specification rather than a pitch: purpose, inputs, outputs, the workflow it runs, the benefits worth expecting, and a note on how the pieces fit together.
Most agent descriptions are demos, and a demo tells you nothing about the twentieth run. A specification is checkable. You can hold it against your own systems before a call and answer the three questions that decide the project: do the inputs exist, does the output land somewhere a person already looks, and which steps would your team insist on keeping?
None of these pages report a measured outcome for a named client. Where an estimate appears it is a range that depends on your volume and your data, and it is labelled as one.