Engineering,on autopilot.

Writing code was never the hard part. The real work starts after: reading the issue, opening a PR, reviewing it, fixing CI, and merging. Moa does all of it. But the agent only reasons; deterministic code runs every git action, so it never pushes to your default branch. You keep the merge button.

  • Never pushes to main
  • You approve every merge
  • Only the repos you allow

Sign in with GitHub · connect a repo in minutes · revoke anytime.

6
workflows, one engine
0
direct pushes to main
1
merge button, yours
mainfeat/issue-142THE AGENToracles/ts · rust · …cited · read-onlyISSUElabeled · moaMERGEchecks greenREAD-ONLYREADtask + sourcesGROUNDEDCONSULTask the oracleREAD-ONLYPLANform the approachWRITESEXECUTEwrites the codecommitsREAD-ONLYREVIEWfindings · verdictread-onlyoraclewrites
Safe by design

The agent only reasons. The machine does the rest.

The decision that mattered most: keep deterministic engineering separate from AI reasoning. The model reads, writes, and reviews code. That's all it can do. Every irreversible action, from committing and pushing to opening PRs and merging, is plain, predictable code outside the model. So a dangerous mistake simply isn't available to it. That line is what makes Moa safe to leave running.

The machine
deterministic code
  • gitbranches, commits & pushes
  • githubissues, PRs, reviews, labels, checks
  • verifyruns the build: node, rust, go, python
The agent
reasoning only
  • readsissues, PR text, review threads
  • writescode, or a review of a diff, nothing else
  • runs asread-only or autonomous, you choose

The agent never pushes. It can't reach the network either, so a malicious issue or comment can't trick it into leaking or fetching anything.

The lifecycle

One issue, all the way to merge.

Moa picks up the issue, writes the fix, reviews the PR, gets CI green, and merges. The agent does the thinking; the deterministic machine around it moves the work along, so an issue goes from open to merged without you babysitting it.

readannotates only, never changes your codewriteswrites code to a branch
Issue
GitHub issue opened
Triage
label · comment
read
Solve
branch · code · verify
writes
Pull Request
branch pushed
Review
findings · verdict
read
Fix-CI
read logs · push
writes
Address
resolve threads
writes
Merge
checks green
Review → request changes loops back to Address.Fix-CI / Address push new commits, so the PR is handled again.Triage only annotates; it never opens a branch.
Six workflows

One engine. Six kinds of work.

Triage, solve, review, fix CI, address feedback, merge. One engine runs all six, the same way every time. Start a workflow from the dashboard or the moa CLI and watch its live step timeline.

one engine
Triage
$ moa wf triageread-only

Triage

Reads a new issue, sorts it, adds the right labels, and leaves a comment. Never touches code.

read issuecategorizeapply labelscomment

read-only reviews · writes code on a branch · started from the dashboard or the moa CLI.

The moa CLI

The whole engine, from your terminal.

The dashboard is one way in; the moa CLI is the other. Same server, same workflows, no context switch. Install it, log in, and drive triage to merge without leaving your shell.

install
then moa login, and it bootstraps a key for you
moa — zsh
$moa wf solve fnLog0/moa 42 --watch
run wf_8c21 · issue→PR · fnLog0/moa#42
✓ branch moa/issue-42
✓ agent wrote 3 files · reasoned, never ran git
✓ verify typecheck · lint · build
✓ open-pr #57 ready for review
done in 1m48s · $0.06
$
--watch streams the live step timeline · runs are the same ones the dashboard shows
Guardrails

Isolated. Cancellable. Timed out if it hangs.

A coding agent should never be able to run forever. Every run is sandboxed and tracked step by step, capped by concurrency limits, timeouts, and a spending budget. Cancel it whenever you want; if it stalls or overruns its budget, it stops on its own. Nothing leaks between runs.

queued
waiting for a free slot
01
running
agent working, step by step
02
succeeded
PR, comment, or labels done
03
failed
errored, timed out, or nothing to change
canceled
you stopped the run
why it's safe to leave running
Isolated
Each run works in its own throwaway copy of the repo, so runs never step on each other and every one starts from a clean slate.
Cancellable
Kill any run instantly. Nothing is left half-applied, and nothing reaches your repo until you approve it.
Self-limiting
Concurrency, timeouts, and a spending budget bound every run. If it hangs or runs over, it stops on its own.

Put the loop on autopilot. Keep the merge button.

Connect a repo and watch an issue become a reviewed PR. The agent reasons; it never pushes to your default branch.

Request early access

Managed early access or a dedicated server · we'll reach out.

How the agent thinks

Understand first. Write last.

Grounding beats reminding. Every run reads, checks the knowledge it needs, and plans before it changes a single line. Writing is the last thing it does, never the first.

1. Read
read-only

Reads the task and the relevant project sources to understand what it is being asked. Changes nothing.

2. Consult oracles
deterministic

Checks the right knowledge base when it needs to, so the plan is grounded in your stack, not guessed.

3. Plan
read-only

Forms a concrete plan from what it read and learned. Still no edits.

4. Execute
write

Carries out the plan: writes the code or produces the review. The only state that can change anything.

Review and triage stay read-only the whole way through. They look, report, and never change a line of your code.

Grounded oracles

Give the agent a domain expert on call.

Instead of asking the agent to remember how a codebase works, give it a domain expert to consult. Each oracle is a read-only knowledge base, and the agent checks the right one before writing a line, so it follows your stack's real patterns and answers with citations instead of guessing. Twenty-six ship today, and you can add as many as you like.

26

expert domains ship today, and each is just a folder of docs, so you can add your own.

  • Read-only & sandboxed
    answers only from its knowledge base, nothing else.
  • Consulted, not guessed
    a real step before the agent writes; its answer shapes the plan.
  • Just a folder
    drop in a folder of docs to add a new domain.
26 shipping today
ts-engineerpython-engineersecurity-engineercode-reviewerts-engineerpython-engineersecurity-engineercode-reviewer
ts-engineerpython-engineergo-engineerrust-engineersql-engineerbash-engineerfrontend-engineertesting-engineercode-reviewersecurity-engineergit-engineerdocker-engineerci-cdts-engineerpython-engineergo-engineerrust-engineersql-engineerbash-engineerfrontend-engineertesting-engineercode-reviewersecurity-engineergit-engineerdocker-engineerci-cd
observabilityapi-designdata-analystgrowth-analyticsproduct-managerproduct-designerdesign-systemsvisual-designerux-researcheraccessibilityprompt-engineertechnical-writerresearcherobservabilityapi-designdata-analystgrowth-analyticsproduct-managerproduct-designerdesign-systemsvisual-designerux-researcheraccessibilityprompt-engineertechnical-writerresearcher
Every one is a read-only knowledge base the agent consults before it writes. Add your own by dropping a folder into oracles/.
Closed-loop memory

It remembers every move, and learns from it.

Every run leaves behind a structured trail Moa can follow later: issues, PRs, reviews, fixes, and the files behind them, all connected. Future runs retrieve what happened before they act, so the agent stops repeating mistakes and starts feeling like a teammate that knows the repo. Instead of starting from zero every time, the system gets better.

the graph, as Moa builds it
repoissuePRreviewCIcommitfileroot cause
Captures every action
Triage, solve, review, fix CI, merge, and audit are each recorded automatically, connected to the work they came from.
Ask in plain English
"Why did this fail?" · "Has this bug happened before?" · "Which files break the most?" All answered from what Moa has seen, with links back to the source.
Learns from failures
Before fixing CI, it looks up how the same failure was solved last time, then writes the new fix back. Every run makes the next one smarter.
Get in the loop

Request early access, or a dedicated server.

Managed early access, or a fully isolated deployment on your own compute so your data and secrets never leave your environment. Tell us which and we'll reach out.

No spam. We'll only use this to reach out about early access.