Morph by Modelcode (modelcode.ai) runs autonomous code modernization with an audit trail: engineers approve the plan for each milestone, the agent carries it out on its own, and the record keeps what the agent was cleared to do, what it decided along the way, where it stopped to ask for help, what it proved, and who accepted the result.
What changes when the agent works alone?
With an assistant in the editor, a developer accepts or rejects each suggestion, and that developer is the record: they saw every line before it existed. Autonomous modernization takes the person out of the middle. Between two human decisions, the agent plans tasks, edits files, builds, runs tests, retries and commits, sometimes for hours. An audit trail for that kind of work has to cover the stretch nobody watched, and it has to make the decisions at either end easy to find.
Autonomy moves review from every step to a few gates. The record is what gives those gates their value: an approval means little if nobody can later open what was approved, see what happened after it, and read the evidence that came back.
A checklist borrowed from security auditing
Security teams already have a vocabulary for this. NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations, includes a control called Content of Audit Records (AU-3). It asks that audit records establish six things: what type of event occurred, when and where it occurred, its source, its outcome, and the identity of the people or entities associated with it. For an autonomous agent, the six become:
What: which milestone ran, how the agent broke it into tasks, and what each task changed.
When: the time of each approval, run, pause and merge, so the order of decisions can be rebuilt later.
Where: the environment the agent worked in, a vendor's sandbox or a machine inside your own network, and the branch it wrote to.
Source: the instruction behind the work, meaning the approved plan item and the team rules in force when the agent ran.
Outcome: the results of the tests and quality gates, including the checks that could not run at all.
Identity: which actions the agent took and which a named person took, kept apart from each other.
AU-3 was written for information systems in general, and meeting it does not make a migration tool compliant with any framework. It is still a fair test of a vendor's record: if the record cannot answer one of the six questions about an autonomous run, someone will eventually have to answer it from memory.
Five things autonomy should still record
The mandate. What the agent was cleared to do before it started: the scope, the target, the constraints, and the spend someone agreed to.
The stops. Every point where the agent could not go on, and what happened next. A run that hits a wall should pause and say so, not skip the hard part and report success.
The agent's own decisions. Patterns it adopted, workarounds it chose, fixes it made to the build. Kept only in the agent's context, they vanish with the run, and the next run and the next auditor lose them.
The proof, gaps included. Evidence that behavior was preserved, next to an explicit account of what was not checked.
The human acceptance. Who approved, who merged, who turned a lesson into a rule, and when.
How Morph records an autonomous milestone
The mandate is approved twice. The Project Spec (target stack, high-level migration plan, key design decisions, repo map, testing strategy) must be approved before Morph plans the roadmap. Each Milestone Spec, which sets out the milestone's scope, the files involved, its design choices and its risks, is approved before that milestone starts. On Morph's credit-based plans, a "Start this milestone?" dialog shows the run's cost in dollars and credits, and nothing starts until someone approves it. Queued milestones are locked, so the plan cannot shift underneath a run.
The starting point is pinned. When a project is created, Morph records the commit SHA of each repository's origin branch. Mainline work that lands later shows up against that baseline, and syncing it into the migration becomes a milestone of its own, reviewed like the rest.
Access is checked before each step. Before Morph generates a spec, sets up a project or starts migration work, it confirms it can read, push to and open pull requests on every repository it changes, and refuses a step whose check failed. On GitHub it works through the Modelcode GitHub App; on GitLab and Azure DevOps, pull requests are opened with the project creator's connection.
The run leaves a trail as it goes. Once a milestone is approved, the agent works autonomously on a branch of its own: it breaks the milestone into tasks, takes them in turn and commits at the end of each one. Every task has an ID (M1-T001, for example) and a status, and progress is persisted, so the run is on the record whether or not anyone watches it.
Blockers are written down, not worked around. Since November 2026, a run that hits a problem it cannot solve alone, such as a registry it can't reach, a service behind a VPN, an expired sign-in or a missing secret, pauses instead of failing or skipping the work and calling it done. It files a blocker issue with what is blocked, the evidence and its suggested fixes, and the project owner gets an email. A help chat that works in the run's own workspace records what was done in the issue and asks before marking it resolved; it cannot commit or push, so only the resumed run changes the branch. If the team tells it to proceed without the missing piece, the run reports that part as blocked and never as passed. Afterward, Code Review lists these issues in an Execution Blockers group, each with what was done about it.
What the agent learns is written back. Before working, an agent reads the Project Spec, the project setup, the rules, the relevant wiki pages and the milestone description. Afterward, it writes new patterns, architectural decisions and fixes to the lifecycle scripts back into Project Knowledge, mostly as wiki pages, where the next agent and any reviewer can read them.
Evidence travels with the work. At the Medium and High validation levels, Morph exercises the migrated application itself. High adds the original: Morph starts it before anything changes, records how it behaves as a baseline, and compares the new version with that recording. Starting with milestone two, every functional test from earlier milestones is replayed as a regression suite; a failure there goes to the team for a decision instead of silently blocking or passing. Morph ships the integration tests it used to verify each milestone along with the code.
People make the final call, on the record. A milestone's work reaches the team as pull requests on GitHub, GitLab or Azure DevOps, where it goes through the usual review and merge process, and no change lands on the mainline until someone explicitly approves it. Comments on the spec, milestones, wikis and rules carry the author, a timestamp and the quoted text, and resolved or outdated ones stay visible. A rule drawn from a merged pull request stays a draft until someone publishes it, and an edited rule changes future milestones, never completed ones. Knowledge chat conversations are saved by default, so a team can reopen a session and see what was discussed and decided; an organization can ask Modelcode to turn that retention off.
One setup detail belongs in any audit plan. When Morph commits and pushes a run's work, the repository's git hooks (husky, lint-staged, commitlint, pre-commit) do not run. If the team relies on a hook to enforce a check, that check belongs in CI on pull requests, or in a lifecycle script such as lint so Morph runs it during validation.
How other tools leave a record
GitHub's Copilot cloud agent keeps its record at the level of the commit and the session. GitHub describes it as designed to be auditable and traceable: the agent's commits are authored by Copilot with the developer who assigned the task marked as co-author, they are signed, each commit message links to the agent's session log, and session logs and audit log events are available to administrators. The developer who asked for a pull request cannot approve it, and the agent cannot approve or merge one. GitHub adds a caution about those logs: "Logs do not replace your own review and testing."
AWS Transform continuous modernization, generally available since August 2026, makes modernization a recurring practice. It scans connected repositories on demand or on a schedule, prioritizes what it finds, and at your direction opens pull requests with validated code changes. Findings accumulate from scan to scan, so the record reads as a history of what each analysis found, alongside the pull requests raised to fix it.
Morph keeps its record at the level of the milestone: the plan and spend approved before a run, what happened inside it, and the evidence and human decisions after it. The right shape depends on the work: the longer a job runs between human decisions, the more the record needs to hold beyond the code itself.
Questions to ask about an autonomous agent's record
What exactly did a person approve before the run started, and can you open that version today?
When the agent got stuck, does the record say so, or does the run simply end as done?
Which checks were skipped or could not run, and where is that written down?
At every step, can you tell what the agent did from what a person did?
Where did the agent run, and under whose credentials did it act?
Do the decisions the agent made between gates outlive the run, in a form the next run reads?
Do your own repository checks still apply to what the agent pushes?
FAQ
What is autonomous code modernization?
Modernization in which an AI agent carries out a planned piece of a migration, such as a framework upgrade, a module port or a service extraction, from start to finish without a person approving each edit. People still set the scope, approve the plan and decide what merges.
What should the audit trail of an autonomous agent contain?
Enough to answer six questions about every run: what happened, when, where, on what instruction, with what outcome, and who did each part, agent or person. In practice that means the approved plan and spend, the run's tasks and commits, any blockers and how they were resolved, test results with the checks that were skipped, and the human approvals and merges.
What does Morph do when a run hits a blocker?
It pauses, files a blocker issue with the evidence, and notifies the project owner. The run waits up to seven days; if the blocker is still open then, the run stops, the milestone fails, and the owner is told. Nothing blocked is reported as passed.
Can Morph merge its own work into the main branch?
No. Your team reviews and merges the pull requests of every milestone, and the full migration comes back as one last pull request into the branch you chose as its target. Nothing lands on your mainline unless a person on your team approves it.
For the layers a finished migration's audit trail should hold, read Auditable AI Code Migration: What an Audit Trail Should Contain; for what each change should hand its reviewer, read AI Code Migration With Human-Reviewable Changes: What Each Change Should Give a Reviewer.
More on Morph: https://modelcode.ai/?utm_source=substack&utm_medium=blog&utm_campaign=autonomous_audit_trail