Skip to content

v1.14.2-ce — Agentic reliability + index correctness

Released: 2026-08-10 · Tag: v1.14.2-ce · Docker: synapcores/community:v1.14.2-ce

Upgrade recommended

Three index-maintenance defects in this release returned silently wrong query results on tables with a TEXT PRIMARY KEY or a secondary index. They are pre-existing, not new in v1.14.1.x. Everyone should upgrade.

One behaviour change to know about

CREATE AGENT now rejects an unknown persona instead of silently downgrading it to a generic prompt. See Upgrading.

Durable agents behave the same on run 1 and run 100

A durable agent replayed a shared conversation transcript into every run, and the engine stripped the tool evidence when saving it. Each run then few-shot-learned from a falsified record that said "answer without calling a tool" — so run 1 called its tools and run 10 quietly did nothing, with nothing in the product making that visible.

Durable agents are now stateless by default. Working memory is a per-run scratchpad; nothing is replayed unless you opt into memory = 'persistent', and when you do, tool evidence round-trips faithfully and stays isolated per (agent, subject) — two agents sharing a persona can no longer teach each other.

Agents fail loudly instead of silently

  • _system_agent_runs tells the truth. New tool_calls_made, iterations_used and exit_reason. A run that finished without calling a tool reports completed_no_tools, not success. A model stuck re-issuing the same call reports stalled instead of burning to the iteration ceiling.
  • _system_agent_transcripts is queryable and preserves tool_name / tool_args / tool_result per turn.
  • Unknown personas are rejected at CREATE AGENT, with the available list in the error.
  • Tool-incapable models are caught early — a write-enabled agent pinned to an embedding-only model is refused at creation.
  • Repeat-call guard stops an agent re-issuing an identical tool call instead of duplicating the write.

Personas are first-class objects

CREATE PERSONA compliance_reviewer WITH (
  system_prompt = 'You are a compliance reviewer.',
  response_type = 'text',
  tool_enabled  = true
);

SHOW PERSONAS;
DESCRIBE PERSONA compliance_reviewer;
ALTER PERSONA compliance_reviewer SET (model = 'qwen2.5-coder:7b');
DROP PERSONA IF EXISTS compliance_reviewer;

CREATE/ALTER PERSONA reject a model that is not installed, and name the installed ones in the error.

Terse prompts drive agents; conversational ones don't

In a controlled A/B on identical task, model and engine, a five-word persona ('You are a compliance reviewer.') executed the instructed statement 3/3, while the conversational built-in default managed 0/3 — it greeted, asked for the user's name, and ended completed_no_tools. For unattended agents, keep the prompt task-shaped.

Agent chaining

WAKE AGENT <name> queues a run on demand. Schedules accept sub-minute cron ('*/10 * * * * *'). An agent's own writes can trigger another agent only when the binding opts in with ALLOW AGENT ORIGIN, and cascades are capped at 5 hops with self-loops refused.

Index correctness — silently wrong results

DELETE left index entries behind on TEXT primary keys

CREATE TABLE t (id TEXT PRIMARY KEY, v TEXT);
INSERT INTO t VALUES ('A','a');
DELETE FROM t;                 -- 1 row deleted, COUNT(*) = 0
INSERT INTO t VALUES ('A','a');
-- Before: ERROR: Duplicate key
-- After : succeeds

Row ids were removed from the index only when they parsed as an integer, so an INTEGER primary key worked and a TEXT primary key leaked on every delete — which is why this looked intermittent. A deleted key could never be reused, and a UNIQUE value freed by an UPDATE was still reported as a duplicate.

UPDATE skipped explicit secondary indexes

CREATE INDEX t_cat_idx ON t (cat);
UPDATE t SET cat = 'blue' WHERE k = 'b';
-- Before: WHERE cat='red'  still returned b     (stale)
--         WHERE cat='blue' returned nothing     (never indexed)
-- After : both correct

Index maintenance was gated on the constraint list rather than the index catalog, so a column indexed with CREATE INDEX — which creates no constraint — was never maintained.

A zero-match index lookup errored instead of returning empty

A lookup matching no rows failed with Column 'x' not found in available columns: … instead of returning an empty result.

Validation

On the published artifact, non-AVX-512 hardware: feature_validator 88/88; recipe certification 160/162 from a pristine data dir with zero regressions; model loads and EMBED returns 384 dims with 0 SIGILL; /version reports 1.14.2-ce.

Agent reliability, 10 consecutive runs of a 3-agent compliance pipeline: 10/10 produced a hash-chained ledger, 117/117 agent runs called their tools, 0 ended completed_no_tools, and 19 rulings across 3 subjects were perfectly consistent with no contradictions.

Known issues

  • COUNT(<column>) counts NULLs produced by an outer join: LEFT JOIN with no match returns 1 where SQL requires 0. Pre-existing; affects aggregates over outer joins.
  • Verifying an immutable table returns success for an empty chain, so a job that wrote nothing still reports "verified". Read the record count alongside it.
  • A single run of a multi-subject agent queue may not drain every pending item (coverage varied 1–3 of 3). Rulings produced are correct and consistent.

Upgrading

Drop-in from v1.14.1.1-ce, with one behaviour change: CREATE AGENT now rejects an unknown persona. Previously any string was accepted and silently downgraded to a generic assistant prompt while the audit still said success.

If you have agent SQL referencing a persona you never created, either create it, use a built-in, or opt out per statement:

CREATE AGENT my_agent PERSONA 'my_custom_persona' ...
  WITH (allow_unknown_persona = true);

aidb-assistant — the persona used throughout the documentation and by the shipped recipes — is a built-in in this release, so existing agent SQL that references it keeps working.

Install

docker pull synapcores/community:v1.14.2-ce
curl -fsSL https://get.synapcores.com | sh
curl -fsSL https://get.synapcores.com | SYNAPCORES_VERSION=v1.14.2-ce sh