mega inside out
agem read backwards is mega. A short tour of the software that writes agem — repositories, code, requests, agents and sandbox.
agem read from end to start is mega. It is a four-letter coincidence, but it describes well what exists on each side of this platform. On this side, agem: the site, the language, the doors. On the other side, mega: the software that makes all of this appear. Today we turn the word inside out and look at the other side.
mega is a simple interface for three things that usually live apart: repositories, pull requests and agent runs. The three enter through the same door, with the same grammar, without changing colour each time you press a button.
- 01repoview PRs, runs and commits
- 02runbranch, agent and files?↺Q&A
- 03agentclaude or codexclaude⇄codexcan swap mid-run
- 04sandboxisolated work
- 05reviewquestions + dev mode05iter
- 06PRclear body and pause
The path to this article
The flow is the one happening right now: a request arrives as text, mega confirms sources and logins, the agent is chosen, the sandbox opens the repository, changes code, validates the result and hands over a PR. Easier to see than to read. Below is a guided tour — tap a number to jump, hit auto to let it run. Each step is a mega screen, with the red marker showing where we are.
Guided tour of mega software
step by stepconnect the sources
Connect sources lists three cards: the Gitea repository link and the Claude and Codex logins. Each card shows whether it is connected and who handles auth behind the scenes.
The landing page is a repository list. Each line is a destination — in our case, agem/agem-site, the repository that holds the site you are reading. Entering a repository opens its detail: branches, recent activity, shortcuts to code and to open requests.
Inside the detail there is a code tab: file tree on the left, file on the right, no distractions. Next to it lives the PRs tab — a list of proposals in motion, each with title, author, source branch and state. Opening a PR shows the full conversation: description, changed files, comments, automation state, and a merge button when the time comes.
So far, this is an honest forge: repositories, code, requests. What changes in mega is what comes next.
The layer you do not see
Each PR can be tied to an agent run. First come the sources: available repositories, the user Gitea session, and Claude or Codex logins stored as opaque Vault material. Then a short brief in plain text is handed to the selected model, which boots an isolated sandbox with the repository mounted, tools, secrets, and a timeline visible live. The agent reads, writes, commits, opens the PR and hands back the link.
Underneath, small named skills run in chain: one asks what is missing in the brief before starting; another emits timeline events; another handles commits and PR creation; another applies feedback that arrives later. They are pieces that link together without needing to know about each other.
In parallel runs the dev mode: the sandbox exposes the app port through a tunnel with a public URL, server logs streaming in real time, endpoints, continuous testing and secrets in the same panel. The code the agent has just written stands up, within reach, before merge.
mega is not the opposite of agem; it is the same word pointing the other way. One side shows. The other side builds.
agem note
Why it matters
Because a platform made of many doors needs a calm way of writing software. Without mega, each .agem service would have its own workshop, with its own rules. With mega, the workshop is one: a request comes in as text, leaves as a PR, and the person in charge is still the person writing the request.
This pass already opens the run from inside: connected sources, agent choice, the work timeline, the sandbox breathing, and the dev URL appearing live before merge.