Why Specify exists
A decision made in one agent session is hard to reuse when the next session starts without it. Specify gives that decision a record: content, a source, an owner and a history.
Work holds tasks and Memory holds reusable context. Security, Briefings and Convert address policy decisions, source-based updates and file processing. Each has its own access and release requirements.
Specify Design is coming. The plan is to let people review revisions generated by external agents and retain design rules with their supporting evidence. It is a specification, not an available product.
What guides the product
- Records before summaries
- Keep the underlying fact and its source so a person can check what an agent reports.
- People review proposed memory
- Agent proposals wait for a human decision. Corrections retain earlier versions.
- Access belongs to the record
- A shared account or link is not permission to read private material.
- Separate approval from execution
- An approval records a decision. Completion needs its own evidence.
- State the limits
- A product illustration does not establish deployed processing, adapter coverage or delivery.
- Use the agent you already run
- The MCP interface exposes scoped tools. It does not require all work to happen in one model or conversation.
What is available
Create an account to see the products enabled for it. Some workflows remain behind release gates; account creation does not enable every service.
The developer guides describe request schemas and authorization boundaries. Use the live access response to check what a particular agent credential can do.
This site uses example records to explain workflows. Sample people, files and activity are illustrations, not customer results.