Decide with people.
Execute with agents.
Verify the result.
A look at how a small team turns architecture, security review, technical planning, and written acceptance criteria into software built with agents and how the result is checked before it becomes part of Centra.
This document explains the development methodology behind the Centra project. It is not a technical specification, a user guide, or a product pitch. It is an honest account of how the system is built: the human team, the decision pipeline, and the role of AI in turning their decisions into reality.
The method is designed for a small team carrying a broad technical surface. It makes responsibilities, handoffs, acceptance criteria, and verification visible before the implementation begins.
We are writing this because we believe the way software is built matters as much as what it does. Transparency about process builds trust. Clarity about methodology makes the product comprehensible. And an honest account of how decisions are made is itself a form of accountability. When someone asks, "How did this get here?" there should be an answer that is more specific than "a developer wrote it."
Four people. Each a specialist.
Four human specialists own the architecture, security review, technical planning, and engineering foundation behind Centra. Agents carry implementation tasks from written specifications; the human team remains responsible for the decisions, review, and software that ultimately ships.
The team is small by design. Each specialist can trace their work through the entire pipeline, challenge the artifact from the previous phase, and make the handoff explicit. The structure reduces ambiguity without pretending that alignment happens automatically.
The architect designs the system.
This is the top-level design phase: what the system needs to do, how the pieces connect, what constraints the design must satisfy, and what the system will look like at scale under load, under failure, and under evolution.
The architect thinks through questions like: What are the core parts? How do they communicate? What happens when something fails? What are the integration points with external systems? What happens when the system needs to change?
The architect does not prescribe implementation details. That comes later. The architect defines the skeleton and the rules that govern it. Every decision at this level is intentional: not aspirational, not borrowed from a template, but designed for the specific problem the system exists to solve. If a design choice cannot be justified with a specific reason tied to a specific requirement, it does not belong in the design.
The architect is also the author of this document.
The security specialist takes the architect's design and attacks it.
This is adversarial review: finding weak points, identifying attack surfaces, and determining where the design introduces risk. The security specialist thinks like an attacker, not like a builder. The goal is not to validate the design but to break it. If the security specialist cannot find a way to attack the system, they have not looked hard enough.
The output of this phase is a set of security requirements that get added to the design. This includes authentication, authorization, data handling rules, encryption policies, and audit logging. Each requirement includes a threat model: what is being defended against, what the attacker could do, and what mitigations are required.
Nothing proceeds to implementation planning until the design has passed this review. Security is not an afterthought or a checklist completed before release. It is a structural phase that hardens the architecture before a single line of code is planned. Security that is bolted on after the fact is security that has already failed. Security that is designed in from the beginning is security that can be verified, maintained, and evolved.
The technical planner takes the hardened design and creates a detailed implementation plan.
This person brings deep technical knowledge at the low level: hardware, runtime environments, platform limitations, and everything that determines whether a design that works on paper will work in reality. Where the architect thinks in systems, the technical planner thinks in machines.
The output is a precise plan: what technology each component uses, where it runs, what dependencies are required and why, what the hard limitations are, and what tradeoffs are being made. This phase bridges the gap between architectural intent and executable reality.
The technical planner also identifies risks that are invisible at the architectural level: performance bottlenecks, platform quirks, and limitations that could invalidate design assumptions. The planner documents these risks alongside the plan, so the team makes informed choices rather than optimistic ones. When the planner says something cannot be done, the team listens. When the planner says something will be difficult, the team accounts for it.
The foundation engineer takes the plan and lays the technical groundwork.
This includes project structure, build system configuration, formatting rules, quality standards, testing setup, and the complete development environment. The foundation engineer defines how code is written, not just what it does.
This phase ensures that when code is produced, it is produced within a consistent, enforceable, and well-maintained framework. There is no ambiguity about organization, conventions, or procedures. The foundation engineer's output is the rulebook that governs every subsequent line of work.
The foundation engineer also establishes the toolchain that the AI agents will use. The agents are only as good as the tooling framework they operate within, so this phase is critical to the quality of everything that follows. A well-tooled agent produces better work than a brilliant agent with poor tooling. The foundation engineer understands this and treats tooling as a first-class deliverable, not an afterthought.
Each phase earns the next.
Architecture establishes the system boundary. Security review attacks it. Technical planning turns it into executable work. The engineering foundation makes the standards enforceable. Each phase consumes and challenges the output of the one before it.
The result is a specification with scope, constraints, dependencies, and success criteria. Agents implement against that contract, surface gaps when the contract is incomplete, and return evidence for the team to review.
The Traditional Model vs. Our Model
Architect writes spec
→ hands to developers
→ developers interpret spec
through their own lens
→ code is produced
(with interpretation drift)
→ code reviewed
(often catching drift too late)
→ bugs fixed
(expensive, after the fact)Architect designs system
→ Security reviews & hardens
→ Technical planner specifies
→ Foundation engineer tools
→ SPEC COMPLETE
→ Handed to AI agent
with full context & constraints
→ Agent implements against spec
→ Checks and review expose drift
→ Agent or human corrects the work
→ Human accepts the verified resultPeople own the intent, the judgment, and the decision to ship. Agents carry implementation and verification work. The specification is the shared contract and the evidence is how both sides learn where it was incomplete.
A deliberate design choice.
The goal is to place human attention where judgment matters most and use agents where repository-scale execution, iteration, and evidence gathering create leverage. The boundary is deliberate, but it is reviewed whenever the work exposes a better one.
Understanding how a complex system fits together, anticipating what could go wrong, and designing for situations that have not happened yet.
Thinking like an attacker, finding vulnerabilities that automated tools miss, and recognizing that the most dangerous threats are often the least obvious ones.
Finding solutions when the requirements are contradictory, the resources are limited, and no textbook answer exists. This is the domain of judgment, not computation.
Choosing when security matters more than convenience, when simplicity matters more than completeness, and when getting it right matters more than getting it fast. These are context-dependent decisions that require experience.
Agents can inspect many files, follow references, compare implementations, and bring the relevant context into one working thread.
A documented sequence of repository checks, edits, tests, and verification can be carried consistently and recorded as it happens.
Commands, changed files, test output, and acceptance criteria can remain attached to the task instead of being reconstructed at handoff time.
When a test fails or review finds a problem, the agent can continue from the same specification and evidence rather than starting a separate effort.
Agents let specialists spend more time on architecture, threat models, and review while implementation work moves in parallel with a written standard.
The boundary is practical rather than ideological. People and agents both make mistakes; the method gives those mistakes somewhere visible to appear before the work is accepted.
Outcomes the team can verify.
A clear acceptance bar
Work is accepted against written behavior and verification criteria. When an attempt drifts or a check fails, the result remains unfinished.
A traceable change
Specifications, execution records, changed files, and timestamps make it possible to understand what moved and why.
More leverage for a small team
Agent execution expands how much implementation a focused group can carry, while architecture, security, and release judgment remain human responsibilities.
Reusable standards
Conventions and checks live in the repository and toolchain, giving each task the same starting standard while still requiring review of the actual result.
A history of the product
When changes stay connected to specifications and decisions, the repository explains not only what exists now but how it arrived there.
Knowledge outside any one head
Important decisions, constraints, and operating procedures live in artifacts the next person or agent can inspect and challenge.
The Centra team believes that the separation of design and execution is the future of software engineering. Humans should do what humans are best at: thinking, evaluating, deciding, and designing. Machines should do what machines are best at: executing with precision, consistency, and speed.
This model does not replace engineers. It elevates them. It frees the human team from mechanical implementation work so they can focus on the problems that require judgment, creativity, and experience. It turns engineers into architects, security analysts, technical planners, and tooling designers, roles that demand human intelligence, while delegating the translation of those decisions into code to systems that are purpose-built for that task.
The product you are using is the result of that philosophy. With the exception of Cortex, the agent runtime and memory substrate that powers our development system, Centra application code is written by AI agents operating from human-authored specifications. Every line is governed by a human-authored spec, reviewed against that spec, traceable to an execution record, and backed by the human team responsible for the system.
This is the method we use because it keeps human judgment close to the decisions that matter and gives agent execution a standard it can actually be checked against.
The method is part of the product.
This is how Centra is built. This is how it will continue to be built. The methodology is not a one-time decision. It is the operating system of the project. It governs every decision, every architectural choice, and every evolution of the system going forward.
The process will keep evolving, but the responsibility will not move: people set the direction, the work is checked against explicit criteria, and the team owns what ships.