MLA: Live Decision Coordination for Codex

Ask anything across your workspace. Every answer cites its evidence and respects your access policy, so you can act on it.
The Impact Feed shows what Meetless governed recently, including the contradictions it caught and you acted on.
Meetless auto-detects claim-to-claim contradictions and routes each for a human verdict before work ships on stale assumptions.
Standing rules your sessions inherit. Approve one and it becomes authoritative memory in every future run; rejects stay for audit.
Decisions are captured live from the working session, not typed up after. Promote to keep, hide to discard.
A human stays in the loop on every learned decision. One click to Trust, one to Dismiss, with the source always a click away.
Human decisions sit beside the exact files the agent read to reach them, so accountability and evidence live in one view.
The evidence library. Every serve-eligible document grounds answers as inherited evidence, with scope and live serving status.
Drill into any document to see its individual claims and the full audit trail of how it was ingested, reviewed, and accepted.
Immutable audit trail plus governed controls: tombstone a document from serving or redact its text while keeping hashes and history.
The coding agent investigates a decision diff by pulling grounded evidence straight from Meetless over MCP, not from guesswork.
Same investigation, deeper: the agent cross-checks the diff against real coordination-case data before drawing a conclusion.
Ask the agent to write and it grounds the whole document in retrieved workspace knowledge, turning a diagnosis into a cited proposal.
Governance is enforced, not suggested. Every write bypass the agent attempts, via Write, shell, or append, is denied by a hook.
Proof in the agent's own words: a system-level enforcement block it cannot bypass. Zero violations across four escalating attacks.

Inspiration

Coding agents are becoming active participants in software delivery, but they do not share a reliable understanding of what the team currently believes.

A team may have multiple developers, coding agents, documents, chat threads, tickets, and work sessions moving at the same time. One session may decide to replace an architecture. Another agent may still be implementing the previous approach. A document may describe an old decision confidently enough that an agent treats it as current.

The problem is not simply that agents forget information. The problem is that decisions keep changing while work is happening.

Traditional search and RAG help agents find relevant information, but relevance does not establish whether that information is still current, whether it has been superseded, or whether another team member has made a conflicting decision in a different session.

Our stale-context benchmark helped isolate this failure mode. When agents received a confident but outdated project summary, they often accepted it without checking whether the underlying decisions had changed.

We built MLA by Meetless to act as a live decision coordination layer for humans and AI agents.

MLA monitors decisions as work happens across sessions and team members. It identifies when new work conflicts with existing decisions, gives agents the context they need to revise their approach, and surfaces the conflict to people when human judgment is required.

For OpenAI Build Week, we extended that coordination loop into OpenAI Codex.

What it does

MLA keeps work consistent while multiple people and agents operate in parallel.

As developers and agents work, MLA continuously captures relevant decisions, constraints, and changes. It compares new information with the team's existing governed knowledge and identifies when two pieces of work no longer agree.

When MLA detects a conflict, it can follow two paths.

If the current decision is already clear, MLA gives the affected agent the governing context, including what changed, what was superseded, and the supporting evidence. The agent can then revise its plan without waiting for a person to restate information that the team has already decided.

If the conflict requires a new decision, MLA surfaces it to the appropriate people instead of allowing the system to silently choose a side. Once the team resolves the conflict, the updated decision becomes available to other sessions and agents.

Inside Codex, MLA provides this through three connected capabilities:

Prompt-time governance

When a developer submits a prompt, MLA injects instructions that tell Codex how to treat project evidence. Codex is instructed not to assume that a relevant document is automatically current.

Governed retrieval

Codex can use MLA's MCP tools to retrieve current decisions, superseded decisions, constraints, evidence, and citations.

Action interception

Before supported tool actions execute, MLA evaluates the proposed action against governed rules. It can return an advisory warning or deny a supported action before execution when an enforceable rule applies.

Warnings and denials are also recorded in MLA's enforcement audit trail.

Our demo follows one connected development task:

Codex receives a task that depends on an outdated architectural assumption.
MLA injects its governance instructions while Codex is working.
Codex retrieves the newer approved decision through MLA.
MLA returns the governing decision, what it replaced, and supporting citations.
Codex revises its implementation approach.
During the same task, Codex attempts to write documentation to a prohibited location.
MLA denies that write before execution and explains the applicable rule.
Codex corrects the action and writes the document to the approved location.
The enforcement incident appears in MLA's audit trail.

MLA is warning-first by default. The hard block in the demo applies to a supported documentation-location rule with denial explicitly enabled. General decision conflicts are surfaced to the agent or escalated to people rather than automatically blocked in every case.

How we built it

MLA already had a connector-neutral governance core that supported knowledge retrieval, rule evaluation, decision provenance, and enforcement auditing.

For Build Week, we added a Codex connector without duplicating those systems.

The Codex integration uses two hook events.

UserPromptSubmit

When a developer submits a prompt, the hook invokes MLA's prompt-grounding flow.

MLA adds a governance floor to the Codex session as developer context. This tells Codex to consult governed evidence when a task depends on project decisions, constraints, or previous agreements.

The prompt hook does not attempt to inject every potentially relevant decision. It provides the operating instructions and directs Codex to retrieve the specific evidence it needs.

PreToolUse

Before supported tool calls execute, Codex sends the proposed action to MLA's existing rule evaluator.

The Codex connector directly reuses MLA's production PreToolUse enforcement command. No second rule engine or Codex-specific enforcement system was created.

The result can be:

an advisory warning,
a request for human attention,
or a denial with a human-readable explanation when a supported enforceable rule applies.

When Codex receives a warning or denial, it can revise its approach instead of continuing without understanding why the action conflicts with team policy.

MCP integration

We packaged MLA's existing MCP server as a native Codex plugin.

Through MCP, Codex can retrieve:

current approved decisions,
superseded decisions,
project constraints,
evidence and provenance,
citations,
and relevant governance state.

This is different from ordinary repository search. MLA is not only returning documents that match the prompt. It is returning the information that currently governs the work.

Connector installation

The connector registers MLA-owned entries in Codex's global hooks.json file while preserving unrelated user hooks.

Installation is deterministic and idempotent:

repeated installation does not create duplicates,
existing user-owned hooks remain untouched,
uninstall removes only MLA-owned entries,
and malformed configuration is not silently overwritten.

Connector installation, repository activation, and Codex hook trust remain separate actions.

A repository is connected to MLA through its existing .meetless.json binding. In repositories without a valid MLA binding, the hooks return immediately without contacting MLA services or creating enforcement incidents.

Codex also requires users to review and trust hooks through /hooks. Until that happens, Codex may skip the hooks and continue normally. The installer therefore does not claim that governance is active merely because registration succeeded.

We used OpenAI Codex and GPT-5.6 throughout the Build Week implementation. The repository identifies the new Build Week commit range, the existing MLA components that were reused, the decisions made by the human developer, and the Codex session where the core connector functionality was built.

Challenges we ran into

Relevant information is not necessarily current

An outdated ADR may be the most relevant document for a task while still describing an approach that the team has already replaced.

We had to preserve the distinction between retrieval and authority. MLA models decisions, supersession, evidence, and approval separately instead of treating every matching document as equally trustworthy.

Decisions change while agents are working

A static context package becomes stale as soon as another team member or agent makes a newer decision.

The system therefore cannot rely only on context injected at the beginning of a session. MLA has to participate continuously while work is happening and reconcile changes across sessions.

Automatic correction and human judgment are different

Not every conflict should stop work, and not every conflict should be resolved automatically.

When an approved governing decision already exists, the agent should receive it and revise its approach. When the conflict represents a real unresolved choice, MLA should surface it to people rather than inventing an answer.

Keeping that boundary clear was central to the design.

Codex hook installation and hook trust are separate

Registering hooks does not guarantee that Codex will execute them.

Until the user explicitly reviews and trusts them through /hooks, Codex may silently skip the hooks. In that state, MLA governance is inactive and actions proceed normally.

We had to make this limitation explicit in the installation experience and avoid presenting registration as proof that enforcement was active.

Plugin-bundled hooks were unavailable

The tested Codex version supported packaging the MCP server as a plugin, but lifecycle hooks had to be registered separately through the top-level Codex hooks file.

We implemented a small reconciliation layer that manages only MLA-owned entries while preserving the user's existing configuration.

Keeping the connector small

The fastest implementation would have been to copy the existing connector scripts and create a second Codex-specific governance path.

That would have been fast but wrong.

Instead, we directly reused MLA's existing PreToolUse command, MCP server, rule evaluator, enforcement audit path, and repository binding. The Codex-specific implementation contains only the packaging, hook registration, and one thin prompt-grounding wrapper required by the Codex surface.

Honest enforcement boundaries

Codex hooks provide a real pre-execution control point on supported tool paths, but they are not a universal security sandbox.

MLA does not claim that it can reverse arbitrary network requests, database mutations, remote Git operations, published packages, transmitted secrets, or every possible tool action.

The demo shows only behavior that we verified against the tested Codex version.

Accomplishments that we're proud of

We are proud that the Build Week project:

extends MLA's live decision coordination loop into OpenAI Codex,
makes current project decisions available inside active Codex sessions,
returns governing decisions with evidence and citations,
helps Codex revise its approach when it encounters superseded information,
distinguishes automatic agent correction from conflicts requiring human judgment,
evaluates supported actions before execution,
returns clear warning and denial reasons directly to Codex,
records enforcement incidents through MLA's existing audit path,
preserves user-owned Codex hooks,
remains inert in repositories that are not connected to MLA,
cleanly separates connector installation, repository activation, and hook trust,
and adds a thin connector instead of duplicating MLA's governance core.

We also connected our stale-context research to a real development workflow.

The benchmark isolates the failure mode. The Codex integration shows how live governance can help an agent recover while it is actively doing the work.

What we learned

Search answers:

What information looks relevant?

Reliable agents need answers to a different set of questions:

Is this information still current?
What superseded it?
Who made or approved the replacement?
What evidence supports it?
Does another active session disagree?
Can the agent revise automatically?
Does this conflict require a human decision?
Which other work may be affected by the resolution?

These are coordination and governance questions, not only retrieval questions.

We also learned that adding more context is not enough.

A larger prompt can still contain conflicting or stale information. The agent needs a system that maintains relationships between decisions, tracks their current status, and participates in the workflow when those relationships change.

The most important insight was that consistency cannot be solved one agent session at a time.

Teams now operate through many concurrent surfaces. A decision made in one session may affect another developer, another agent, a document, a ticket, or an implementation already in progress.

The system has to monitor and reconcile those changes across the team while the work is happening.

What's next for Meetless

The Codex connector is one surface of a broader coordination system.

Our next step is to connect MLA to the tools where teams already discuss, document, decide, and execute work.

These connectors will include:

communication platforms such as Slack,
documentation systems such as Confluence and Notion,
issue trackers such as Jira and Linear,
source control platforms such as GitHub,
project management systems,
development environments,
and additional AI agent platforms.

MLA will monitor decisions across these systems, reconcile information that refers to the same work, detect conflicts as they emerge, and maintain a governed view of what currently applies.

Any team member, or their AI agent, will be able to engage with MLA from the tool they already use.

When the current answer is already known, MLA will provide the governing context so the person or agent can revise their approach.

When a new decision is required, MLA will surface the conflict to the appropriate people, capture the resolution, and make that updated decision available across connected sessions and tools.

The long-term goal is for MLA to become the coordination layer that keeps humans and AI agents aligned across every place work happens.

Search finds information. MLA keeps decisions and work consistent as the team moves.