Getting Started
Synentra provides Intent-Aware Runtime Governance for AI Agents. It controls requests to registered HTTP APIs and MCP tools, evaluates governance, obtains human approval where required, and records admitted work for controlled execution.
Choose your path
- Concepts: read and understand Concepts about Synentra
- New users: read this introduction, then follow QuickStart.
- Administrators: configure identity, persistence, and governance bundles.
- Developers: use the API overview and HTTP integration.
- Operators: begin with troubleshooting.
- Contributors: follow the development workflow.
The request journey
An agent submits an operation and arguments. Synentra identifies the caller and evaluates the request. Allow proceeds toward admission; review pauses for a reviewer; deny stops the request.
Admission records the authorized operation and target. A worker checks current authority before dispatch. The response separates governance, approval, execution, and verified outcome. Approval is not completion, and a response is not always proof of the intended effect.
Current contracts
| Contract | Value |
|---|---|
| REST API | /v2 |
| Invocation | synentra.invocation.v2 |
| Invocation result | synentra.invocation-result.v2 |
| Bundle API version | synentra.io/v2alpha2 |
| Bundle kind | GovernanceBundle |
| MCP entry point | /mcp/{serverId} |
Implementation Status
The v2 implementation includes identity resolution, manifest validation and activation, declarative and OPA policy evaluation, approvals, task grants, durable admission, HTTP/MCP dispatch, credential providers, and persisted audit records.
Boundaries that affect deployment
| Area | Current behavior |
|---|---|
| Semantic intent | The registered baseline intent provider returns unavailable/error; supply a working implementation before relying on classification. |
| Intent profile thresholds | The inspected evaluator uses required-provider status and onUnavailable; separate enforcement of minimumConfidence and onLowConfidence is not demonstrated. |
| Obligations | Contracts and handlers exist, but general handler orchestration is not invoked in the inspected decision engine. |
| Telemetry | OpenTelemetry integration exists; its startup registration is commented out. Logs and stored audits are separate. |
| Execution models | Baseline adapters support request-response. Other model names in schemas or enums do not establish working async, streaming, or batch transports. |
| Outbox attempts | The inspected worker uses its own batch/attempt limits; do not assume all similarly named settings control that loop. |
| Retention | Credential-aware filtering does not filter every credential-free payload. |
| Reconciliation | Records outcome evidence without replaying the mutation; does not automatically settle all budgets or replace transport state. |
Configuration is not implementation
A provider name in an example or a plugin metadata entry does not install an implementation. Discover deployed capabilities and validate the bundle before activating it.
Development settings allow local networking and relax key-ring protection. They are for local evaluation, not production defaults.
Documentation scope
The QuickStart supplies a small HTTP example without custom resolvers or required intent. Identity tokens still come from your configured provider. No authentication bypass or bundled identity service is assumed.
The diagnostics reference records actual code paths, including inconsistent response shapes and diagnostic identifiers where present. These limitations are documented rather than presented as completed functionality.