Capabilities snapshot
Vera operates within a declared capability snapshot. She can't use tools, network access, or system resources that aren't explicitly permitted by operator policy — even if asked.
Vera is the conversational and planning surface inside VoxeraOS. She converses with you, investigates questions, shapes intent, and prepares governed requests for the VoxeraOS execution runtime. She does not directly mutate the system.
"Vera asks before she acts."
The trust boundary
Vera helps you think, prepare, and investigate. VoxeraOS asks, gates, executes, and records.
Vera is the conversational surface. VoxeraOS is the governed execution and evidence layer. They are deliberately separate — and that separation is what makes AI actions trustworthy.
Reliability constraints
Vera operates within a declared capability snapshot. She can't use tools, network access, or system resources that aren't explicitly permitted by operator policy — even if asked.
Every risky action goes through the approval gate before execution. Vera surfaces the reason and scope; the operator decides allow or deny. No action bypasses the gate.
Vera's planning loop uses a fixed prompt structure — no improvisation on the system prompt. The planning context is traceable and inspectable via artifact bundles.
Today
Queue a natural language goal — "Write a daily check-in with priorities and blockers" — and Vera structures a governed write request. VoxeraOS executes it, records the artifact. No free-form improvisation.
Status checks run through a read-only lane. Vera queries your environment using the system.status skill and returns a structured summary — no ad-hoc shell execution, no side effects.
Vera can plan a multi-step mission from a high-level goal, break it into steps, and hand each step to VoxeraOS — which evaluates policy, gates on approval if needed, and executes.
When a provider fails, Vera classifies why — TIMEOUT, AUTH, RATE_LIMIT, MALFORMED, NETWORK — and surfaces the reason in voxera queue health and voxera doctor.
On request, Vera assembles queue state, job artifacts, and system snapshot into a structured handoff package — ready for operator review or escalation.
After VoxeraOS completes a job, Vera translates artifact data and structured logs into readable summaries for the operator — closing the loop on every governed action.
Broad direction
Respond to "Hey Voxera" and handle voice-first commands through the same approval-gated queue. A future direction — details will evolve.
Structured planning previews with explicit operator confirmation pathways — see exactly what Vera intends to do before any step runs.
Signed skill bundles so operators know exactly what Vera is allowed to do — and can verify it. No unsigned skill execution.
Vera is built on a tiered brain system with deterministic fallback handling and structured prompt ordering. The planning loop is inspectable via artifact bundles.
Brain tier system: primary, fast, reasoning, fallback — each independently configurable per provider. OpenRouter is the only officially tested and fully built provider path so far. Gemini 3 Flash is the current minimum supported requirement. Other OpenRouter brains can be tried experimentally.
Fallback classification: when a provider fails, the failure reason is classified into one of: TIMEOUT, AUTH, RATE_LIMIT, MALFORMED, NETWORK, UNKNOWN. The reason persists in health.json and surfaces in voxera queue health.
Prompt ordering: Vera's planning loop uses a fixed prompt structure. The system prompt, capability snapshot, and job context are composed in deterministic order. No runtime improvisation on the system prompt.
Fast path: common write operations (note writes, file writes) use a deterministic fast-path that emits exactly one files.write_text step — no cloud planning required.
See Vera in action
Queue a job, watch Vera plan it, approve the execution, and inspect the audit artifact — in a single voxera demo session.