The MGV Gateway

The technology behind how we build

The Gateway gives AI agents defined jobs, sets limits on what each job can change, and keeps a record of the result. Independent reviewers challenge the work; a person decides whether the work is ready to release.

Explore the architecture Download this explanation

How it works

One job, start to finish

Follow a bounded code change from the business request to a release decision.

An assigned agent receives one approved job. The Gateway records the result for the assigned independent reviewers.

A person decides what ships.

People can still work with agents directly. This path is for managed work that needs enforced limits and a durable record.

People + lead orchestratorPeople authorize. The lead prepares and coordinates.

The Gateway
enforces and recordsSupported workflows track progress and preserve state for recovery.

Agents
work and review

Set the outcome

Name the business result, who will accept it, and the tests that show it works.

Approve the job

Allow a review or one limited code change. Name permitted files and actions. Wider work needs additional authority.

Load current facts

The lead orchestrator checks current project context, agent availability, and the supported workflow before dispatch.

Enforce the limits

For the supported workflows shown here, the Gateway checks whether a job is allowed before it starts and applies the permissions set for that job.

Return the work

The agent returns advice or permitted edits. The Gateway records the result with the files, checks, and code version.

Adversarial review

Separately assigned agents inspect the exact result without write access. They seek defects and back each criticism with evidence.

Decide what ships

The owner accepts or rejects the work. Push, merge, deployment, and release require explicit human authority, which may be granted in advance.

Limits hold during the work

Operating-system, agent-interface, and repository controls own the actions they restrict. Comparing files afterward checks the result; it cannot replace enforcement. Reviews challenge unnecessary restrictions as well as missing protections.

Status and result stay separate

Process status	Possible actual result
Stopped	Valid edits may already exist.
Finished	The requested change was never made.

Illustrative cases. Recording both facts preserves useful work and prevents an empty result from being mistaken for success.

Failures stay visible

Preserve useful work and verify it against the request and sources. Complete a missing step under existing authority. Do not replay an uncertain action. A fresh attempt needs a changed condition and the right authority.

Current scope: workflows tested in MGV’s macOS environment; Linux and multi-tenant operation are not yet tested. Cline and Goose edit without commit authority. Only the supported Codex workflow permits one explicitly authorized local commit, created by its trusted adapter. Review-only jobs do not change code.

One approved job
One assigned agent
Work within limits
One job record
Independent fault-finding
A person releases

More about permissions and ownership

Inside the softwareLangGraph coordinates supported workflow steps. The Gateway controls the agent call and records its result. Git identifies the code version. Slack exchanges with interactive agents are a separate coordination channel.

Advice and code changes use different routesRecorded read-only review preserves output and a terminal run record. Explicit Open Review is a separate admitted option without that durable record. Bounded code changes use qualified agents, a permitted scope, checks and required review. The detailed architecture explains these routes and when a separate formal record is available.

Coding permission is not release permissionPush, pull-request creation, merge, deployment and release remain separate authorized actions. A completed run is not release approval.

Why it matters

More work can move forward.
Accountability stays clear.

Move faster from an idea to peer-reviewed working software, with a clear path through testing and release.

Practical challenge	How the approach helps
Project context is scattered across conversations.	A shared project record reduces repeated briefing.
A technical pass is not the same as customer readiness.	Code, approval, deployment, and customer readiness remain distinct.
Written expectations can be missed during delivery.	Relevant checks are built into the delivery process.
Different delivery approaches involve different tradeoffs.	Independent challenge helps you choose before committing further effort.
Duplicate launch paths increase maintenance.	One owner for each action reduces repeated fixes.
Agents have different operating capabilities.	Qualification makes those differences explicit before work begins.

For project teams

Spend more time building

You give each job current context, clear limits, and a defined result. Separate reviewers examine the work before it advances. The next session can continue from the record, reducing repeated explanations and avoidable rework.

For operations

Recover without repeating work

You can see what ran, what changed, and where work stopped. Interrupted coordination can resume without replaying an uncertain action.

For technology buyers

Add agents through one method

Each agent is assessed for its interface, permitted work, and operating environment. That assessment remains useful while those conditions hold. A new organization still validates its own setup; the shared method gives it a repeatable starting point.

Who decides what

Clear ownership,
at every level.

You set the outcome and authorized scope. Agents implement and independently challenge each other’s work. A lead AI agent weighs conflicting reviews against their supporting records, within the direction you set. You retain final acceptance and release authority.