Tentrico documentation

What is Tentrico?

Target design1 min read

A control plane that turns intent into verified software outcomes.

Tentrico is a software-delivery control plane. It coordinates requirements, AI agents, human decisions, testing, environments, releases and evidence, so that what you asked for can be shown to be true.

It optimises for Intent → Evidence rather than Prompt → Code. Code generation is one execution capability inside a larger governed delivery system.

Tentrico is designed to sit over the tools you already use for source control, CI/CD, infrastructure, security and observability, not to replace them. It owns orchestration, traceability, policy, decisions, human escalation and evidence.

Product principles

Target design1 min read

The rules every part of Tentrico is designed to preserve.

• Intent is represented as Requirements, and requirements must stay internally consistent.
• Important ambiguity becomes an explicit Decision.
• Work is executed through Missions and Tasks.
• Agents escalate unavoidable human dependencies through Human Tasks.
• Completion requires Evidence mapped to acceptance criteria. An agent saying “done” is never sufficient.
• Build artifacts are immutable and promoted, not rebuilt per environment.
• Production access is governed, least-privileged and auditable.
• Agents are workers, not authorities: independent verification stays separate from implementation.
• Every important state transition is recoverable and recorded as an Event.

From intent to evidence

Target design1 min read

How a single request moves through Tentrico.

Every piece of work follows the same path, whether it starts as a new requirement, a failed verification, a security finding or a bug.

1. Intent
2. Requirement
3. Integrity check
4. Mission
5. Build
6. Review & test
7. Evidence
8. Verified

• You describe an outcome in natural language. Tentrico proposes a structured, testable requirement with acceptance criteria.
• An integrity check looks for duplicates, conflicts and ambiguity before any implementation starts.
• An approved requirement creates a Mission, which is planned into tasks and assigned to agents.
• Work is reviewed by an agent other than the one that built it, and tested against the acceptance criteria.
• Evidence is linked back to each criterion. The requirement is verified only when that evidence holds.

See this path end to end on the How It Works page. Watch one intent become verified

Requirements

Target design1 min read

Living, versioned statements of what must be true.

A requirement is a statement of something that must be true. Requirements are added incrementally in natural language and normalised into structured proposals with rationale, priority, acceptance criteria, risks and dependencies.

• Each requirement has a stable ID, for example REQ-AUTH-014, and an immutable version history. Changes create versions rather than overwriting.
• A requirement stays Proposed until it passes integrity analysis and any required human approval.
• Requirements link to the work, tests, reviews, decisions, releases and evidence that relate to them.

Before a Mission is created, every new or changed requirement passes an integrity check:

Decisions

Target design1 min read

Durable human resolutions of conflict and ambiguity.

A conflict or important ambiguity creates a structured Decision rather than a chat interruption. The decision shows the competing requirements, what they affect, the available options, a recommendation with its rationale, and the consequence of each choice.

• Reject the new requirement.
• Replace or supersede an existing requirement.
• Introduce a scoped exception.
• Modify both requirements.
• Defer the decision, or provide a custom resolution.

Approved decisions are kept as immutable records of what was decided, why and by whom. Agents receive them as project context, so they don’t later simplify away an intentional constraint.

Missions and tasks

Target design1 min read

The execution container for approved work.

A Mission is created from an approved requirement, a requirement change, a failed verification, a security finding, a bug or an explicit objective. It moves through Understand → Plan → Build → Verify → Deliver.

• Planning breaks the work into tasks with dependencies. Tasks can run in sequence or in parallel.
• Agents are assigned through explicit policy and capability routing.
• Work runs in isolated contexts, such as separate Git worktrees, where appropriate.
• Independent review is normally done by a different agent from the implementer.
• Mission status comes from real task states, tests, approvals and dependencies. There are no invented progress percentages.

Human Tasks

Target design1 min read

A structured way for work to wait for a person, then resume.

When an agent or workflow needs a person, it doesn’t just stop. It creates a Human Task, waits, and declares what response it needs and exactly what happens after you respond.

Completing a task isn’t automatically resolving it. The workflow checks that the requested condition now holds and either resolves the task or returns it to Waiting with an explanation.

1. Created
2. Waiting
3. Submitted
4. Validating
5. Resuming
6. Resolved

Verification and evidence

Target design1 min read

How completion is proved, and how proof goes stale.

Evidence is the bridge between “the agent changed something” and “the requirement is satisfied”. Each acceptance criterion can reference one or more pieces of evidence.

Evidence has freshness. When relevant code, configuration, design or infrastructure changes, the evidence behind a requirement can become Stale and trigger re-verification.

Environments

Target design1 min read

Governed, first-class runtime contexts.

An Environment represents everything that makes up a runtime context: its endpoint, release, deployment provider, data stores, infrastructure, configuration, secret references and policies.

“Implemented”, “verified in QA” and “verified in Production” are tracked as different states for the same requirement.

Releases

Target design1 min read

Build once, promote the same artifact everywhere.

1. Source
2. Build once
3. Immutable artifact
4. QA
5. UAT
6. Production

• Application artifacts are built once and promoted through environments, never rebuilt per environment.
• Infrastructure and configuration are declarative and version controlled. Plans are reviewed before they are applied.
• Environment secrets are referenced, never packaged.
• A release brings together application artifacts, infrastructure, migrations, a requirement manifest and verification reports.

Policy and security model

Target design1 min read

Agents get capabilities, not uncontrolled access.

Every agent request passes through a policy engine that considers identity, workspace, environment, capability, risk, required approvals and audit before a connector reaches a remote system.

1. Agent request
2. Policy engine
3. Connector
4. Remote system

• Agents receive capabilities rather than raw credentials wherever possible.
• Production defaults to least privilege and read-only agent access.
• High-risk actions require explicit approval according to policy.
• Secrets don’t belong in chat transcripts, task descriptions or diagnostics.
• Instructions found in repositories or remote content are never treated as authorisation.
• Policy decisions are enforced independently of model output.

The Security page covers trust boundaries and deployment models in more depth. Explore security

Events and audit

Target design1 min read

An immutable record of every meaningful change.

Every important state transition emits a structured, immutable event. Events feed the workspace dashboard, the audit timeline, notifications and requirement health.

Teams and shared state

Planned1 min read

What a shared control plane syncs, and what stays local.

Tentrico is designed to be local-first. A shared control plane, planned for teams, synchronises collaboration objects while source and execution stay local by default.

See how this scales from one developer to an enterprise on the Solutions page. Explore solutions

Integrations

Planned1 min read

The tools Tentrico is designed to coordinate.

Integrations are capability-based connectors behind policy enforcement. Tentrico coordinates mature tools rather than rebuilding them. Availability will vary by release.

MCP can extend Tentrico broadly, but an MCP server never bypasses Tentrico policy.

Workflow states

Target design1 min read

Explicit, recoverable states for missions and Human Tasks.

Mission and task execution:

1. Queued
2. Running
3. Waiting for agent
4. Waiting for human
5. Resuming
6. Verifying
7. Complete

Missions can also end Failed or Cancelled. Human Tasks can end Cancelled, Expired or Failed.

• Transitions are validated centrally and are safe to repeat.
• Restarting doesn’t lose blocked work.
• A duplicate callback or double-click never resumes a workflow twice.

Glossary

Target design1 min read

The shared vocabulary used across Tentrico.