Kernel tools first
Cerberus can read files, search the web, inspect pages, search local code, manage memory, and attach artifacts before it ever needs a custom extension.
Cerberus AI core
Tater's execution engine is a guarded planner loop, not a single-shot reply generator.
Cerberus is the runtime that decides what happens between a user request and a finished answer. The codebase frames it as a closed-loop Planner -> Doer -> Checker architecture that can complete tasks by smartly chaining kernel tools with Verba Plugins, backed by validation, repair, recovery text, state persistence, and runtime limits.
Task completion
The real Cerberus feature is smart chaining, not just tool calling.
Verba Plugins where action lives
When the task needs smart-home control, media workflows, image generation, camera events, or app-specific logic, Cerberus switches to the right Verba Plugin.
One step at a time
The chain stays deliberate: choose one action, validate it, run it, update state, then decide whether the next step should continue the task.
Execution loop
Each round narrows to one tool-sized action.
1. Plan Builder
Cerberus turns a user request into ordered atomic steps so multi-action requests become a clean chain instead of one oversized tool call.
2. Planner
The planner chooses exactly one next action, selecting the best kernel tool or Verba Plugin for the current step with a strict current-message tool gate.
3. Validation and repair
Tool calls are forced into strict JSON, checked against the tool catalog, repaired if malformed, and blocked if the tool is unsupported or disabled.
4. Doer state update
After a tool runs, Cerberus updates goal, plan, facts, open questions, next step, and tool history so the next round stays grounded.
5. Checker
The checker returns exactly one of FINAL_ANSWER, RETRY_TOOL, or NEED_USER_INFO and decides whether another atomic step is still required.
Guardrails
Why Cerberus is more reliable than a loose tool-calling loop.
- Current-message tool gate: Cerberus does not continue past work unless the current turn explicitly asks it to.
- Smart chaining: kernel tools and Verba Plugins can be mixed across steps to finish a task instead of stopping after one tool result.
- Atomic execution lock: the planner and checker both focus on one next step instead of merging unrelated actions.
- Recovery text path: validation failures can trigger a short recovery message instead of a broken tool call.
- Ledger and metrics: Redis-backed state keeps history, limits, and validation outcomes visible to operators.
- Memory context: user and room memory summaries can be injected into checker decisions without bloating the turn.
Default runtime budgets