The control plane under the agent.

Zdravo is a Next.js application backed by Supabase PostgreSQL + pgvector, with object storage and model providers behind application boundaries. The runtime connects agent identity, requests, policy evaluation, execution state, evidence, and audit records into one governed path.

AI agent / client
        ↓
Authentication + governed identity
        ↓
Request / MCP invocation
        ↓
Decision Spine + policy evaluation
        ↓
ALLOW / DENY / ASK_HUMAN
        ↓
Execution + observation
        ↓
Evidence + audit
        ↓
PostgreSQL + pgvector

Memory is stored in PostgreSQL, with pgvector providing semantic retrieval. Structured metadata, ownership boundaries, policies, decisions, observations, and audit state remain in the same database layer.

• Vector dimension: 768 for the current embedding contract
• Similarity search: pgvector HNSW indexing
• Filtering: ownership, organization, memory type, department, clearance, and other metadata
• Embedding providers: local and hosted providers are selected through the application embedding layer
• Graceful failure paths preserve memory state when embedding work cannot complete immediately

The runtime does not treat an authenticated request as permission to act. Governed agent identity and organization binding are established first, then policy is evaluated before an action is authorized.

• ✓Agent identity is bound to an organization before governed decisions
• ✓MCP API-key authorization is bound to the authenticated organization and governed identity
• ✓Required governed invocation and decision state transitions fail closed when persistence fails
• ✓Policy outcomes are explicit: ALLOW, DENY, or ASK_HUMAN
• ✓Decision and invocation records provide a durable control-plane trail

Successful governed execution is completed with durable observation state and evidence. Observation completion is atomic so the runtime cannot silently report a completed action while leaving its evidence transition inconsistent.

• ✓Governed observations are tied to the invocation and decision that authorized them
• ✓Atomic completion persists the required observation and evidence state together
• ✓Audit records provide inspectable history for governed activity
• ✓Hash-chain provenance is used for tamper-evident audit evidence

MCP is an agent-facing interface, not a bypass around governance. Requests entering through the MCP server are authenticated and associated with the governed organization and identity before protected actions proceed.

• MCP server exposes the current governed context capabilities
• API-key authentication carries organization binding into the runtime
• Protected runtime paths require a governed invocation
• The same policy and evidence model applies regardless of the agent-facing entry point

Security is enforced at multiple layers: application authentication, organization and identity binding, PostgreSQL row-level security, tightly scoped database functions, and fail-closed runtime transitions.

• ✓Row-level security on exposed application data
• ✓Security-definer functions are restricted to cases that require elevated database privileges
• ✓User-scoped RPCs use SECURITY INVOKER where RLS already provides the required boundary
• ✓Public share functions validate active, public, and unexpired state
• ✓Guest-memory claiming requires authenticated identity plus device-secret verification
• ✓Internal security functions use fixed search paths and restricted execution grants

The production path favors explicit state transitions and recoverable asynchronous work over silent success. The runtime records failure conditions instead of allowing infrastructure errors to become authorization success.

• ✓Idempotency keys protect governed decision creation from duplicate transitions
• ✓Atomic database functions are used where multiple state changes must agree
• ✓Background work can retry failed embedding and observation-related processing
• ✓Health and status surfaces are separated from claims about historical uptime