About PureIntent
PureIntent is an open catalog of reusable product and engineering decisions for human teams and coding agents.
Reuse decisions, not just code
AI coding agents can already write interfaces, APIs, tests, migrations, and infrastructure. The harder question comes first: what should they build, and what behavior should the result preserve?
PureIntent is an open catalog of reusable product and engineering decisions. It turns a rough intention into structured context that a human team can review and an AI coding agent can implement and verify.
Browse blocks. Build a workspace. Give your agent a better starting point.
The blank page is still the bottleneck
"Build an internal AI chat with RAG, file uploads, and web search" sounds like a clear request. It is not yet a buildable specification.
Someone still has to decide how conversations are stored, what happens when generation is stopped, which files are accepted, how retrieval failures appear to users, whether answers need citations, what may leave the company network, what is logged, how access is checked, and how the finished behavior will be tested.
Most of these questions have been answered before. Yet teams repeatedly solve them from scratch because the decision itself is difficult to reuse. Code has packages. Design has component systems. Infrastructure has images and modules. Product and engineering knowledge is usually left in old tickets, private documents, or the memory of the people who built the last version.
PureIntent makes that knowledge portable.
A block is a reusable decision
A PureIntent block is the smallest independently adoptable piece of product or engineering context. It does more than name a feature or recommend a technology. A complete block explains:
- what outcome is required;
- where the responsibility and authority boundary lies;
- which inputs, states, failures, and edge cases matter;
- which choices remain project-specific;
- how an implementation can be verified;
- which other blocks it requires, complements, conflicts with, or replaces.
A block may also include examples, schemas, fixtures, diagrams, a reference implementation, or an agent skill when those artifacts make the decision easier to adopt correctly.
From intention to working software
1. Describe the outcome
Start with what you want to achieve, not a complete specification. For example: "Build a private support assistant that answers from company documents and cites its sources."
2. Find a set or individual blocks
Search by problem, capability, role, platform, stack, or constraint. Start from a curated set when one matches the outcome, then add or replace individual blocks where the project differs.
3. Add project-specific decisions
Record the facts that generic blocks cannot know: the existing stack, data boundary, identity provider, deployment environment, supported users, budgets, and deliberate deviations from the baseline. In PureIntent today, those facts live as project files in your Workspace.
4. Resolve dependencies and conflicts
A Workspace keeps required dependencies visible and separates alternatives from complementary blocks. If an external embedding provider conflicts with a rule that documents may not leave the company, the conflict should be resolved before it becomes code.
5. Export a Solution to the project
Export produces a versioned context package: selected blocks, project files, and pinned versions. It can live beside the source code and be used by any compatible coding agent.
6. Implement and verify
The agent maps the Solution to the actual repository, proposes a plan, implements it in stages, and reports which requirements and acceptance scenarios are satisfied. Packaged scenarios are specifications until they have been executed in the target project.
PureIntent is not another code library
A code library reuses an implementation. PureIntent reuses the decision behind an implementation.
The same block can guide a PHP monolith, a Go service, a Python application, or a stack that did not exist when the block was written. When useful, a block can include code or a reference implementation, but the portable contract remains the primary artifact.
PureIntent complements frameworks, design systems, SDKs, and package registries. It helps a team decide how those tools should be used together and what the resulting product must do.
A strong baseline, not one universal answer
There is no single correct architecture for chat, payments, search, analytics, or authentication. Products have different users, risks, constraints, and existing systems.
PureIntent provides a reviewed starting point: the questions that normally matter, the failure modes teams often miss, the common options and tradeoffs, and the evidence needed to call the work complete. Adopt it as written, replace a decision, or add a project override. The important part is that the choice becomes explicit and testable.
Written for humans and agents
People need to understand why a decision exists and where it may be changed. Agents need precise boundaries, structured examples, dependencies, and acceptance criteria.
PureIntent serves both audiences from the same source. A product manager can inspect the intended behavior. A technical lead can review contracts and risks. A coding agent can turn those contracts into a repository-specific implementation plan. A reviewer can trace the result back to the decisions that justified it.
Open and portable by design
Blocks are ordinary files with explicit versions and relationships. They can be stored in Git, reviewed like code, downloaded as an archive, adapted privately, and used without a proprietary runtime.
Services may make discovery, assembly, translation, validation, and private catalogs more convenient. The underlying knowledge remains useful outside the service.
Build from accumulated experience
Coding agents are increasingly good at writing a program. PureIntent helps them understand which program is worth writing, which decisions must not be guessed, and how the result should be checked.