Oracle Forge · Yonas Mekonnen

Highlights

▸Three-context-layer architecture: schema context, business-logic context, and query-history context feed the agent.

▸Self-correcting execution loop retries with grounded feedback instead of hallucinating a new plan.

▸Evaluation harness scores answer quality against a ground-truth set so regressions are caught before they ship.

▸Integrates the auditor, refinery, cartographer, event store, and contract enforcer as callable subsystems.

The problem

Analytics agents that hit real databases fail in the same predictable ways: they hallucinate columns that do not exist, they forget the business meaning of a field, and they cannot recover from a bad query. Oracle Forge is a compound system built to survive those failure modes by treating context as a first-class citizen.

Architecture

Schema context: live introspection over Postgres, Mongo, DuckDB, and SQLite, materialized into a compact representation the LLM can reason over.
Business-logic context: definitions and rules pulled from a shared registry so the model does not have to guess what “active user” means.
Query-history context: prior successful queries seed the plan for the current one.
Self-correcting loop: the executor runs a candidate query, surfaces the exact error and a minimal sample of the returned data, then hands control back to the planner.

Compound integration

Oracle Forge does not stand alone. It calls out to earlier TRP1 systems:

The Automaton Auditor grades new queries before they run.
The Document Refinery answers questions where the source is a PDF, not a table.
The Brownfield Cartographer grounds schema decisions in codebase reality.
The Event Store provides history through MCP so the agent can audit its own decisions.
The Contract Enforcer blocks queries that would violate an upstream data contract.

What I learned

Compound systems reward small, well-instrumented subsystems more than they reward larger, cleverer prompts. Every one of these components can be tested in isolation and swapped out.

Trade-offs

If the underlying schema were small and stable, I’d skip the agent entirely and write a deterministic text-to-SQL router — it’s cheaper, faster, and easier to audit than an LLM planner for a query surface you already understand. The self-correcting loop earns its keep specifically because the schema spans four database engines with real drift between them; that’s also the part I’d trust least in production without the evaluation harness catching regressions before they ship. This is a one-week TRP build, not a production system — it hasn’t run against real user traffic, and the integration with the five prior TRP1 systems means a bug in any of them can surface here.