Durable knowledge for agentic product engineering
An effective agentic development process cannot depend solely on a Product Engineer remembering earlier conversations or repeatedly explaining the same organizational rules. The SHAPE Framework distinguishes between standing instructions, product specifications, and shared enterprise assets so that coding agents receive the right context and humans can review changes over time.
Three kinds of information
Agent instructions and project context establish how an agent should work, which constraints it must observe, what goals the product serves, and which architectural decisions are already settled. These instructions can be organized into separate self-describing Markdown documents.
Feature specifications describe the intended behavior of the product. They are maintained as version-controlled artifacts and evolve when the agreed behavior changes. Specifications answer questions about what should happen, including business rules, exceptions, and acceptance conditions.
Enterprise assets provide approved and reusable implementation capabilities. They may include selected stacks, services, common libraries, identity and security mechanisms, design systems, components, engineering conventions, and reusable patterns. Ownership and changes to these shared materials are governed beyond any one project.
Standard project conventions
The SHAPE Framework recommends a simple and extensible discovery model for project instructions. A root-level AGENTS.md tells coding agents to read and observe all Markdown files in agent_instructions/. Each file in that directory states its purpose in its opening line or heading. Projects can add their own files, rather than relying on a centrally maintained register of mandatory filenames.
Feature specifications remain in a separate specs/ area. They are not standing instructions: each describes product behavior that the implementation must deliver and that verification should evaluate.
Organization and project responsibilities
The organization maintains standards and approved reusable assets. A project provides its own objectives, applicable instructions, accepted architecture, and feature specifications. The exact mix of documents may differ between a small workflow application and a complex integration product, but the underlying categories should remain clear.
Documentation and implementation must agree
When a product's accepted behavior changes, specifications should change. When a formally approved architectural decision changes, its documentation should change. When a reusable enterprise component changes, its guidance should remain accurate. Contradictory documentation creates uncertainty for both people and agents.
Where controls become enforceable
A text instruction not to access a database does not itself prevent access. The actual ability to read data, execute commands, install software, or connect to services must be constrained by the approved execution environment. The framework treats discoverable instructions and technical permissions as complementary, not interchangeable.
Explore the artifacts
See Specifications for product behavior, Agent Instructions for the standing instruction model, Enterprise Assets & Reuse for organization-level capabilities, and Agent Execution Boundaries for enforced permissions.