Mercury Composable · white paper briefing

Intent-Driven Development

…and the architecture of Human-AI collaboration. The Mercury story — from event-driven systems to AI co-authorship: shared memory, an AI grammar, and governed execution.

Eric Law · with Claude Code and GitHub Copilot · 2026-09-04

The thesis

Prompts → context → intent

Prompts tell AI what to do. Context helps AI understand. Intent explains what matters.

Prompt engineering

Human provides instructions.
AI contributes responses.

Context engineering

Human provides instructions, knowledge, constraints, project specifics.
AI contributes better responses.

Intent-driven development

Human provides vision, goals, boundaries, priorities, judgment.
AI contributes collaboration in analysis, design, implementation, refinement.

Productivity does not come from generating more code. It comes from reducing the distance between human intent and a working, governed system.

Why now

Two problems dominate serious AI-assisted engineering

The governance problem

AI writes imperative code fast — and ungoverned. Enterprises cannot certify what they cannot read, and reviewing machine-authored code at machine speed does not scale.

The context problem

AI agents consume context expensively. The default way an agent learns a dependency is to read its source — a cost that repeats for every dependency, every session, every team.

Mercury answers both — and it started answering them years before the questions were asked.

Origin · 2018

One rule, never broken: functions know nothing about each other

From the actor-model lineage (Scala/Akka) onto the Eclipse Vert.x event bus: every function is self-contained, addressed by a route-name string, exchanging immutable event envelopes. No shared objects. No direct references. Nothing to rot at the joints.

The first architectural invariant — and it has never changed.
For years the honest cost was ergonomics: callbacks and reactive chains.
Java 21 virtual threads dissolved that tax — plain sequential code now performs on par with reactive, so the event-driven core became free to use.

You can only compose what you never coupled.

Evolution

The ascent: code → configuration → knowledge

Each layer removes a class of imperative code. One atom, four roles: the same function is a service under rest.yaml, a task in a flow, a skill on a graph node. The layers compose downward with no coupling.

Layer 3, governed

Compiled — or 404

The semantic layer is guarded the way production software must be. A graph model deploys only through CompileGraph, the mandatory validation gate: a model is compiled and listed, or its endpoint answers 404 as if it never existed.

Dry-run the model in the Playground — with a human and an AI companion in the same live session.
Validate the whole graph at compile time — malformed intent is rejected before it can run.
Deploy as a standard endpoint; suspend/resume gives long-running workflows a built-in human-in-the-loop primitive.

The same compile-before-run discipline code has always had — applied to knowledge.

The turn

Don't review AI code harder.
Change the artifact the AI authors.

An AI that authors a flow or a graph model is producing a declarative, compiler-validated, human-legible artifact. CompileFlows and CompileGraph reject malformed intent at build time; the Playground dry-runs it; a product owner can read it and certify it.

Governed nondeterminism — the creativity of a model author, bounded by gates.

Never a determinism claim. A governance design.

The discipline

Humans provide direction. AI provides leverage.
Governance provides trust.

Humans provide

Purpose and outcomes · boundaries and priorities · architectural rulings and trade-offs · certification of consequential artifacts · the decision to go live.

AI partners contribute

Synthesis and critique · translation of intent into structured artifacts · implementation of bounded tasks · consistency checking · surfacing ambiguity.

Platforms provide

Contracts and constraints · structural and semantic validation · controlled execution · deployment gates · observability and feedback.

Sharpened in practice by specialized reviewer personas invoked on demand — architecture, security, consistency, documentation — structured, independent perspectives for the human architect. Not autonomous replacement: complementary responsibility.

What intent controls

Four forms of drift — and what answers each

Purpose drift: the implementation moves away from the outcome it was meant to achieve — answered by Vision, intent, and human judgment
Context drift: documentation disconnects from the implementation — answered by the AI grammar: versioning, catalogs, manifests, validation gates
Continuity drift: decisions and rationale are forgotten across sessions and tools — answered by shared memory, Blueprints, and architecture decisions
Implementation drift: generated artifacts violate approved designs or contracts — answered by compilers, tests, dry-runs, staged promotion, certification

Acceleration without direction is only faster drift.

Two instruments

Memory explains the project.
Grammar explains the platform.

Shared memory · continuity

Why the project exists, what is true, what was decided and rejected, what happens next. Backward it preserves decisions and provenance; forward it carries intent through Vision → Blueprint → design → implementation → feedback. A new session continues the project instead of reconstructing it.

AI grammar · legibility

What a platform or building block can express, where authoritative guidance lives, which contracts artifacts must satisfy, and how conformance is verified — so behavior is derivable rather than guessable.

Memory without grammar: direction without dependable execution. Grammar without memory: capability without purpose. And in the memory layer itself — mechanize the arithmetic; do not mechanize the judgment.

The AI grammar

Documentation engineered as a machine-consumable contract

An AI grammar is the discovery map, reference guides, machine-readable catalogs, and validation gates that let an AI agent author correct artifacts without reading engine source.

Sufficient

An agent guide may claim “you can generate correct artifacts from this page alone” — and only agent guides may claim it.

Verified

CI binds every claim to the code: drift tests, coverage and link-integrity gates, golden vectors, a version-matched manifest.

Cheap

Measured in tokens, not pages. Discovery in one hop; a map that stays lean enough to read every session.

Shipped today

The grammar Mercury carries

llms.txt map: one-hop discovery — CI coverage gate on the Java engine’s exhaustive map; link-integrity gate on the Rust engine’s curated map
3 DSL spec kits: rest.yaml · Event Script flows · MiniGraph commands — each a grammar reference + machine-readable JSON catalog + AI agent guide + CI drift test
Contract provider: the doc set served as a version-matched contract: discovery endpoint, per-file SHA-256 manifest, exportable Agent Skill
Registration contract: the grammar of declaring functions — one metadata model, per-language carriers, proven by golden vectors shared between engines
Engine parity: Java is the reference; Rust ships in lock-step; flow YAML ports unchanged; python/node functions join as Event-over-HTTP peers
Memory layer: the project’s grammar, via agent-memory — Vision, Blueprint, continuity — so sessions start oriented on intent, not just API shape

The benchmark

Doc discovery and token efficiency

A grammar is useful only if the agent finds the right page in one hop and the map stays cheap. Measured on the Rust engine, 2026-09-04:

~2,500

tokens — the whole discovery map

~46,000

tokens of source-verified reference it routes to, one hop away

~515,000

tokens of engine source — the hunt the map replaces

Completeness that costs discovery is a regression. The map is dense with the exact tokens an agent searches for — and gated in CI so it cannot silently rot.

Proven, not promised

The milestone: fresh agents, grammar only

The ai-enabled-repo-demo exercises put the grammar under load: fresh AI agents — no project context, no human hints — built and ran applications from the grammar alone, through repeated rehearsals and a live demonstration.

Every friction became a fix, shipped to the field in days (v4.12.2): a json simple plugin closing a data-mapping gap, an export-guard correction, recipe lines where two independent agents drew the same wrong conclusion.
Discovery gaps were closed with CI gates behind them, so they stay closed — the coverage and link-integrity gates shipped in v4.12.3.
The loop — agent friction → grammar or engine fix → field release — is the methodology working.

The methodology

How a developer builds with an AI partner

AI-enable the project

Greenfield or existing: install the shared memory layer, write the Vision with the AI partner (human-confirmed, never fabricated), derive the Blueprint, plan increments. Every session thereafter starts oriented.

Add mercury-composable, choose the path

The engine arrives carrying its own grammar. Recommended for applications: Layer 3 — model the service as a knowledge graph, dry-run in the Playground, deploy behind the CompileGraph gate. The path is a dial, not a wall.

Build the app — or a building block

Applications: intent → model → certify → deploy. Building blocks: layer-2 + layer-3 patterns — then compile an AI grammar into the block’s own repo, so it becomes as legible as Mercury itself.

Proof point for step 1: Mercury’s own Rust engine was AI-enabled before its first line of code — about a hundred increments later it ships in lock-step with the Java engine.

The recursion

Grammar composes the way dependencies compose

The session that builds the application loads Mercury’s grammar plus each building block’s grammar. Already live inside the framework: twin-kafka is a building block on a building block — and while its map entry was missing, AI partners fell back to source.

To an AI partner, undocumented capability is absent capability.

Industry context

Standing on recognized practice — then gating it

llms.txt convention: adopted — then held to a CI gate and a token budget, which conventions alone cannot do
Docs-as-code: extended to docs-as-contract: the build fails when a guide and its engine disagree
Architecture Decision Records: the ADR ledger carries durable rationale; memory facts point at it, so agents inherit the why
Contract testing: golden vectors shared verbatim between independent engines — the Pact-style trust mechanism, applied to a port
Agent-instruction files: AGENTS.md and kin, with a routing shim: contributors → the memory protocol; consumers → the version-matched contract
Human-in-the-loop governance: dry-run, compile gates, certification, staged promotion — delivery-pipeline controls applied to model artifacts
Evaluation culture: fresh-agent rehearsals are evals for documentation; the memory smoke test is an eval for project memory — both run on cadence, both produced fixes

Each practice is known. Binding them into one CI-enforced, token-budgeted contract an AI partner can build from — that is the AI grammar.

Parnas 1972 · Hewitt 1973 · Nygard 2011 · Robinson 2006 · llms.txt (Howard 2024) · AGENTS.md · GitHub Spec Kit 2025 · NIST AI RMF · EU AI Act art. 14 · ISO/IEC 42001 · DORA 2024–25 · HELM · SWE-bench — full citations in the white paper’s References section.

Where it goes

The north star does not move

AI agent orchestration on the graph runtime — bounded-agency decision graphs; first experiment already run end-to-end, live LLM verdicts under one distributed trace.
A pluggable AI companion backend — the collaboration layer matures.
The governance lifecycle — dry-run → certify → stage → approve → production, so models promote as standard endpoints.

The Active Knowledge Graph is the application. Humans and AI co-author the model, the event-driven runtime executes it, and changing behavior means editing knowledge — not shipping code.

The working posture

Do not just prompt. Do not just vibe code. Do not expect magic.

Express intent. Define boundaries. Build living context. Guide your AI partners. Review the work. Improve the system.

White paper: Intent-Driven Development and the Architecture of Human-AI Collaboration · accenture.github.io/mercury-composable

mercury·composable ← → to navigate · P to print the handout 1 / 1