SynapCores v1.9 — The database that is the agent runtime

Every "AI agent in your database" pitch so far has really meant a database with an AI function you call. You still wrote the worker that polls, the cron job that fires it, the queue that buffers it, and the glue that keeps them in sync. The database held the data; everything that acted on it lived somewhere else.

v1.9 collapses that. CREATE AGENT makes an agent a first-class schema object — a persona bound to a task, an activation, a governance envelope, and persistent memory, all stored in the database. You INSERT a row; the agent wakes up and acts. There is no external orchestrator, because the trigger, the reasoning loop, the memory, and the audit log are the same engine that holds your data.

One statement

CREATE AGENT incident_triage
  PERSONA 'aidb-assistant'
  TASK 'Triage the incident in the activation row: classify it, name the likely
        attack pattern, and recommend an escalation tier.'
  ON INSERT INTO incidents WHERE severity = 'critical'
  WITH (max_iterations = 3, allow_writes = FALSE,
        timeout_seconds = 90, budget_tokens_per_day = 200000,
        on_budget_exhausted = 'pause');

Insert a critical incident and the agent triages it in the background — off the write path, so the INSERT returns immediately. A non-critical row doesn't match, so nothing fires. That's the whole SOAR pattern — trigger, worker, queue, audit — in one DDL statement.

What "durable" actually buys you

It survives restarts. Definitions reload, cron schedules re-arm on a process-global scheduler, and any queued invocations drain. Restart the engine mid-workload and the agent picks up where it left off.
It fires on events or a schedule. ON INSERT/UPDATE/DELETE … WHERE … binds the agent as an internal after-trigger — a non-matching write costs sub-millisecond overhead and never runs inference in the write path. Or bind it to ON SCHEDULE '0 8 * * *' and it wakes itself every morning.
It cannot run away. The governance envelope — iteration cap, write policy, timeout, and a daily token budget — is declared in SQL and enforced at dispatch. Exhaust the budget and the agent auto-pauses, visible in SHOW AGENTS. Agent-initiated writes never re-trigger event bindings, so no cascade loops.
Every decision is auditable. Each run lands in _system_agent_runs — activation, status, token usage (flagged when estimated rather than exact), duration, and output. Query it like any table.

The full family is here: CREATE / ALTER / DROP / SHOW / DESCRIBE / EXECUTE AGENT. Community Edition allows 10 active agents per instance.

Agent memory got sharper too

Durable agents lean on the memory primitives shipped in v1.8.5 — and v1.9 makes recall better. MEMORY_RECALL now supports a two-stage rerank through a native GGUF cross-encoder (bge-reranker): retrieve a wide candidate set by vector similarity, then re-score the top-K with a cross-encoder that actually reads query and document together. It rides the same in-process model registry as everything else — no extra service, no ONNX runtime, no GPU.

Reliability, because autonomy has to be trustworthy

An agent you leave running unattended is only as good as the engine underneath it. v1.9 also lands: model-resolution fixes so a per-call or per-agent model override is actually honored (and a typo'd model name fails loudly instead of silently running a resident default); a fix for a CREATE TABLE → INSERT schema-visibility race on the hot path; and a batch of SQL correctness fixes (GROUP BY + ORDER BY column resolution, comment-aware recipe parsing, aggregate handling).

Try it

docker pull synapcores/community:v1.9.0-ce

Upgrading from v1.8 is drop-in — no migration, and durable agents are opt-in. Read the CREATE AGENT SQL reference and the Autonomous Incident Triage recipe to see it end to end, then point one at a table and watch it work.