Solutions·Engineering
Каждая session поднимает свой cloud computer, клонирует repo и режет свою branch. Агент воспроизводит failure, пишет patch, гоняет suite и открывает change request. Вы ревьюите diff, а не transcript.
The handoff
Not the architecture. The long tail underneath it — the reproductions, the bumps, the flakes, the mechanical migration across two hundred files. Work that is well-specified, individually small, and collectively the reason nothing else ships.
It takes the report, builds the case on its own machine, and comes back with either a failing test or the reason it could not reproduce. A session that cannot reproduce says so. It does not invent a fix for a bug it never saw.
It runs the suite in a loop, isolates which test actually fails and how often, and finds the shared state or the timing assumption underneath. The change request carries the failure rate it measured before and after.
Upgrade, build, run the suite, read the changelog for the breaking notes, patch the call sites that moved. If the suite goes red it opens the change request anyway — with the failures in the description rather than a green claim.
One rename, one API move, one lint rule turned on — trivial per file and unbearable at scale. It works file by file on its own branch and lands one reviewable diff.
It reads the errors the day threw, clusters them by root cause rather than by message, ranks them by how many people hit them, and takes the top one all the way to a patch.
It diffs the documented behaviour against the actual behaviour and corrects the document to match the code, or flags the code as the thing that is wrong. Both are the same commit type here — everything is a file.
The output
The output of an engineering session is the thing engineering already reviews. There is no new artifact to learn, no summary to trust — the change is the change, and the tests either passed on the machine that wrote it or they did not.
The agent commits on the session branch and opens a change request against main. What arrives in review is a diff with a description — the same object a colleague would have opened.
The sandbox is a real Linux machine, so the agent installs, builds and runs the suite itself. A change request that arrives red says so in the description rather than claiming green.
Sessions do not share a working tree. Twenty of them can run against the same repo at once, each on its own branch and its own computer, without stepping on each other.
Where it reaches
An engineering session already has the strongest reach on the platform, because most of the work is inside the repo it cloned. Connectors cover the rest — and every credential is resolved server-side, never inside the machine.
Cloned into the sandbox at session start, on a fresh branch. The agent has a shell, a filesystem and the full history — it can bisect, run the suite, and read the commit that introduced the line it is about to change.
Read issues, comments and the state of a branch, and write back where you have allowed it. Neuro OS opens the change request itself; the connector is for everything around it.
Pull the ticket that started the session, read the acceptance criteria, and post back the change request link when the work lands. The ticket stays the source of truth for scope.
The live channel. Mention the bot in a thread and that thread becomes a session; the answer, and any file it produced, comes back into the same thread.
Point Neuro OS at an OpenAPI or Postman spec, a GraphQL endpoint, a remote MCP server, or a bare HTTP base URL. It turns every operation into a tool the agent can call.
Anything not in Easy connect is reachable through MCP, OpenAPI, GraphQL or raw HTTP — usually the honest answer for an internal service that never had a public catalogue entry.
How it runs
The same session machinery, started three different ways. Nothing about the isolation or the review changes with the trigger.
Describe the bug in a Slack thread, or start a session from the web app or the CLI. You get a reaction on your own message rather than a bot post, and the reply lands in the same thread.
Set an action to Ask and the run pauses at the call and waits, showing you the action and its arguments. Approve and the same call completes and the session carries on from exactly where it stopped.
Triage the overnight exceptions at 06:00. Or wire your alerting to a signed webhook so a paging event starts a session with the incident payload already in the prompt.
Control
The interesting question about an autonomous engineer is not what it can write. It is what it can land. Here is the answer, stated exactly.
An agent cannot merge to main. The permission exists — an admin can grant it — but the grant lives in config, so widening it is itself a change someone reviews. Nothing about that is a hidden default.
The shipped default is permissive: actions run unless you say otherwise. Set Ask on the ones that should pause and Block on the ones that should never happen. We would rather tell you the default than let you assume the safer one.
One disposable Linux machine per session, on its own branch. The only thing genuinely shared is the world outside — which is why the connectors, not the machine, are where reach is decided.
The sandbox carries one project-scoped token and no third-party keys. The gateway decrypts the real credential server-side and attaches it to the outbound call.
The gateway that resolves the credential is the same thing that writes the record: the action, the agent, the person or trigger behind the session, the outcome, and who released a held call.
The same platform
One project, one set of connectors, one memory that compounds. Each team writes the skills for its own work; nobody stands up a second system.
“Nothing merges itself. You review a diff on a branch — with the suite already run — not a transcript about what might have changed.”
Любая модель, ваши ключи. Neuro OS в вашем cloud, VPC или on-prem.
