{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreieidqzs5qkw4fscuoo6m2wju6zoazq3lab6xuzsry4anxwe2jyapi",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mowblfoeir22"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreians5soha2xbvwv6omrvykdmbamjly7emkcjjq47akm2m5wauame4"
    },
    "mimeType": "image/webp",
    "size": 312522
  },
  "path": "/niclydon/the-confabulation-cascade-when-your-agent-learns-nothing-from-its-own-mistakes-m08",
  "publishedAt": "2026-06-23T01:09:49.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "security",
    "buildinpublic",
    "niclydon.io"
  ],
  "textContent": "My infrastructure analyst agent was stuck in a loop I didn’t have a name for yet.\n\nIt would write a SQL query with a hallucinated column name. The query would fail with a Postgres error. My error handler would fire back the real column list from `pg_attribute`. The agent would read it, acknowledge the correction in its reasoning trace, and then write the exact same wrong column name on the next attempt.\n\nNot a different wrong column. The same one.\n\nI started calling it the confabulation cascade. Here’s what was actually happening, why it’s a tool design problem more than a model problem, and what I did about it.\n\n##  The Setup\n\nNexus is my personal intelligence platform. It runs 8+ autonomous agents against a 191-table Postgres schema, doing things like weekly life chapter analysis, relationship health tracking, and biographical inference from 24 years of personal data. The infrastructure analyst agent is responsible for querying those tables to surface patterns and anomalies.\n\nWhen agents write SQL in Nexus, they go through `handleQueryDb` in `tool-executor.ts`. The handler enforces SELECT-only access, applies agent-scoped roles, and on failure calls `buildQueryDbSchemaHint()` from `query-db-schema-hint.ts` to augment the error message.\n\nThat last part is where the problem lived.\n\n##  The Reactive Schema Hint\n\n`buildQueryDbSchemaHint()` does two things:\n\n  * On “column does not exist” error: introspects `pg_attribute` and returns the real column list for that table\n\n  * On “table does not exist” error: searches `pg_class` for similar table names and suggests them\n\n\n\n\nThis is useful. When it triggers, the agent gets accurate schema information. The problem is the word “when.” The hint is purely reactive. It only fires after a query fails.\n\nThere is no `describe_table` tool. No `get_schema` call. No way for an agent to ask “what columns does `aurora_life_chapters` have?” before writing SQL. The only path to ground truth is trial and error.\n\nSo the agent’s loop was:\n\n  1. Generate a query. Column name comes from training weights plus context – call it a confident prior.\n\n  2. Query fails. Error message arrives with real column list.\n\n  3. Agent processes correction as context in its next generation.\n\n  4. Training prior reasserts. Same wrong column appears in the new query.\n\n  5. Go to 1.\n\n\n\n\nThe agent wasn’t ignoring the correction. It was receiving two competing signals: an error-message correction grounded in reality, and a stronger schema prior embedded in the model’s weights. The correction arrived once. The prior arrived every token. Guess which one won.\n\n##  Why This Is a Tool Design Problem\n\nIt’s tempting to frame this as “the model should pay more attention to error messages.” That framing puts the fix in prompt engineering territory – add emphasis, reorder the context, tell the model to really read the hint this time.\n\nThat might help at the margin. It doesn’t fix the structural issue.\n\nThe structural issue is that I designed a tool surface that makes confident guessing the only entry point to accurate information. The agent had no way to verify structure before acting. It could only learn by failing. When a model’s training prior is strong, that learning channel is lossy.\n\nCompare this to how you’d design a tool for a human. If you give a human an API and they ask what fields it accepts, you give them documentation. You don’t make them submit malformed requests until the error messages teach them the schema. The human version of the confabulation cascade is a poorly documented API with no reference – you keep guessing based on what similar APIs look like, and sometimes the error messages stick, and sometimes they don’t.\n\nSame failure mode. Different substrate.\n\n##  The Fix: describe_table\n\nThe fix is a proactive schema introspection tool. Agents call it before writing queries, not after failing them.\n\nThe implementation is straightforward:\n\n\n    async function handleDescribeTable(\n      tableName: string\n    ): Promise<{ columns: Array<{ name: string; type: string; nullable: boolean }> }> {\n      // Validate input -- public schema only, no injection surface\n      const sanitized = tableName.replace(/[^a-z0-9_]/g, '');\n\n      const result = await db.query(`\n        SELECT column_name, data_type, is_nullable\n        FROM information_schema.columns\n        WHERE table_schema = 'public'\n          AND table_name = $1\n        ORDER BY ordinal_position\n      `, [sanitized]);\n\n      if (result.rows.length === 0) {\n        // Suggest similar tables rather than returning empty\n        const similar = await findSimilarTables(sanitized);\n        throw new Error(\n          `Table '${sanitized}' not found in public schema.` +\n          (similar.length ? ` Did you mean: ${similar.join(', ')}?` : '')\n        );\n      }\n\n      return {\n        columns: result.rows.map(row => ({\n          name: row.column_name,\n          type: row.data_type,\n          nullable: row.is_nullable === 'YES',\n        }))\n      };\n    }\n\n\nRegister it in the agent’s tool grants. Add it to the tool executor dispatch. Done.\n\nThe resulting agent behavior:\n\n  1. Before writing SQL against an unfamiliar table, call `describe_table`.\n\n  2. Get back authoritative column names and types.\n\n  3. Write the query against verified schema.\n\n\n\n\nThe cascade stopped. Not because the model got smarter, but because it no longer needed to guess.\n\n##  The Broader Pattern\n\nIf your agents are writing tool calls against real data stores – databases, APIs, file systems – ask yourself: can they verify structure before acting, or can they only learn by failing?\n\nThe answer changes what class of bugs you’re going to see.\n\nReactive error hints are valuable. They’re not sufficient. An agent that can only discover reality through failure is operating in a state of managed hallucination: wrong until corrected, corrected until the prior reasserts, back to wrong.\n\nProactive introspection tools break the loop at the design level. The agent can ask first. That’s not a prompt engineering fix. That’s a tool surface decision.\n\nIt’s the same principle as the difference between defensive error handling and input validation. Catching the exception is better than crashing. Never constructing the invalid input is better than catching it. Move the check earlier.\n\nFor agents writing SQL: `describe_table` before the query beats `schema_hint` after the failure. The loop that took me a debugging session to understand takes zero sessions to encounter if the tool surface doesn’t require guessing in the first place.\n\n_Nexus is my personal intelligence platform, running on private hardware. The agent runtime, job system, and Postgres schema are all home-grown. Posts about the architecture live at_ niclydon.io_._",
  "title": "The Confabulation Cascade: When Your Agent Learns Nothing From Its Own Mistakes"
}