//Technical

How Meutex is built

Which Google Cloud service does what, which model runs where, how the agents prove who they are to each other, and what a ticket actually costs. The diagrams below are the ones in the repository, not redrawn for this page.

What it is

You label a ticket in GitHub or Jira. A group of agents picks it up: one writes the spec, one writes the code and the tests, one reviews the change for security. You approve at each handoff. Nothing reaches your repository without you saying so.

One issue moving through Task Engine, PM Agent, Forge and Sentinel, with human gates between them — One ticket, end to end. The amber steps are the two points where a person decides; everything else runs on its own.

How it works

Setup is a sign-in and one connection. After that the only thing you ever do is label a ticket.

01Sign inGoogle account, nothing else. First sign-in creates your workspace and puts $2 of free credit in it. No card.
02Connect GitHub or JiraOne click from Connections. Jira goes through the same OAuth handshake. Connect either, or both.
03Meutex GitHub App installsGitHub asks which repositories to grant. It reads code to work out where a change belongs, pushes to a branch of its own, and opens a pull request. It never writes to your default branch.
04Label a ticket meutexCreate an issue or a Jira ticket the way you already do, then add the label. That label is the entire interface — no second dashboard to live in.
05Agents pick it upA webhook fires the moment the label lands, and a sweep every five minutes catches anything it missed. One agent writes the spec, you approve it, another writes the code and tests, you approve that, and a separate agent reviews the diff for security.

Same label in both places: meutex on a GitHub issue, or on a Jira ticket. Take it off again and the ticket is released — the agents stop, and nothing half-finished is left in your repository.

What runs on Google Cloud

Sixteen services. The short version: Cloud Run holds the agents, Firestore holds the state, Vertex AI does the thinking, and the rest is identity, build and telemetry.

Full Meutex platform architecture: every Google Cloud service, service account and OIDC audience — Every service, with the four service account names, the audience on each OIDC hop, the Firestore collections, both Model Armor templates, and the scheduler job. Click it — at full size the labels are readable.

Cloud Run: Four services, one per agent plus the console. None of them accept public traffic; they scale to zero when idle.
Firestore: Every ticket's state: the PRD, the agent's step trail, the security report, who approved what. This is the audit record.
Vertex AI: Both Gemini models. Gemini 3.7 Flash writes the spec and the code; Gemini 3.5 Flash triages security findings.
Vertex AI Agent Engine: Memory Bank. What an agent learned on one ticket, available on the next, scoped so one workspace can never read another's.
Model Armor: Two templates. Screens what goes into a model for prompt injection and what comes out for leaked data.
Agent Registry: Three agents and eleven capabilities published as versioned cards, so other systems can discover them.
IAM + Workload Identity: Four service accounts, one per service. No key files anywhere — tokens come from the metadata server.
Secret Manager: Three secrets: the GitHub App key, the sandbox key, and the internal service secret.
Cloud Scheduler: One job, every five minutes, that tells the platform to pick up anything newly labelled.
Cloud Build · Cloud Storage · Artifact Registry: The deploy path. Source is staged, built, and the image is stored per service.
Cloud Trace · Logging · Monitoring: OpenTelemetry, so one ticket is one trace across all agents rather than four disconnected logs.

Which model, and where

Two, both through Vertex AI, chosen per job rather than one everywhere.

Gemini 3.7 Flash writes the spec and the code. Both need the model to read a repository it has never seen and work out where a change belongs, which is the expensive kind of thinking.

Gemini 3.5 Flash does one narrow job: deciding whether a security finding is real. The scanners have already found it; the model only judges it. A smaller model is enough, and a security review costs about a fifth of a cent because of it.

The frameworks

The PM agent is built on Google ADK. Forge, the agent that writes code, is built on the Antigravity SDK — it needs to drive a real machine, run commands, read what broke and try again, which is what that SDK is shaped for.

They talk to each other over A2A, the agent-to-agent protocol. Every call carries a token addressed to the specific agent being called, so a token minted for one is refused by the next.

What an agent is made of

Each agent is a model, a set of tools, somewhere to remember, and rules about how much it is allowed to hold in mind at once. The differences between the three are the interesting part.

PM Agent, Forge and Sentinel compared by model, tools, memory and context handling — Same shape, three agents. Forge is the only one with a sandbox and a token budget. Sentinel is the only one that keeps no memory at all — its report is the record.

How the security review works

Sentinel reads only what the change added. It clones the branch into a throwaway machine, runs four open-source scanners, works out which findings the diff actually introduced, and asks a model to judge the ones left. A committed password can never be dismissed, whatever the model thinks.

The Sentinel review pipeline from pull request through scanners to verdict — A review takes about twenty-five seconds and costs around $0.002. Findings go to the pull request without their evidence, because a public comment must never carry the secret it just found.

What it costs

Measured over real runs, not estimated: about $0.25 to $0.50 per ticket across all agents, and roughly fourteen minutes of agent time from label to open pull request. Time spent waiting for a person to approve is counted separately, because it is not the system being slow.

What is not built

The deployment agent and the final verify-and-close agent are designed and drawn, not shipped. Everything before them runs today. They appear in the diagrams as dashed boxes marked planned, and it seemed better to say so here than to let you find out later.

Get early access