Aient
AI DevOps
PRODUCTION HAS A WAY FORWARD
Aient brings your code, telemetry, and investigation history together to find causes, test fixes, and check what happens after deployment.
Problems grouped by impact, ready to investigate.
View full-size screenshot01 / AIENT FIXING AIENT
Someone opened a problem to see its investigation and evidence. The screen stopped waiting after 10 seconds. The server returned both responses successfully—but too late for that visit.
Aient picked up two failed requests in the browser when a user opened a problem. The investigation summary and its supporting evidence had both hit the same 10-second deadline.
Open the problem, read the investigation, and inspect the evidence. Instead, the interface abandoned those requests before their results were available.
Aient matched the browser failures to server traces. The requests had not failed on the server: they returned successfully, after the browser had already stopped waiting.
Aient gave the investigation and evidence requests 30 seconds, including evidence refreshes. Other API requests kept their existing 10-second deadline.
All 15 tests in the focused component suite passed.
Aient opened a pull request, addressed review feedback, and the change was merged.
The code and tests establish the change. Confirming the result means checking the user’s experience after deployment:
Still to confirm The affected screen loads successfully after deployment. We are not claiming a measured improvement yet.
Open a problem on the deployed version and confirm that both the investigation details and supporting evidence arrive, including when the server takes longer to start. Correlate that browser journey with its server responses.
We have not yet substantiated that post-fix journey for this case. The intended improvement is more reliable loading; the change does not make the server faster.
Aient can consult recent commits and pull requests, follow repository instructions such as AGENTS.md, and run the project’s tests. Approved knowledge from earlier investigations can inform the next one.
If new evidence shows the problem has returned, the investigation can reopen with its history intact.
“I can ask a question about production and get an answer in seconds instead of spending an afternoon on it.”
Before Aient, tracking down a production problem meant guessing which service to look at, then digging through logs one at a time. The worst ones were the failures that didn’t announce themselves — a service answering health checks normally while something inside it had quietly stopped working.
What changed is that I can ask a question about production and get an answer in seconds instead of spending an afternoon on it. That’s true for incidents, but also for ordinary decisions — when I need to know how something actually behaves under real traffic before committing to a design, I can just look, rather than argue about what feels right.
If you’re considering it: cross-service traces are worth it on their own. Most of our genuinely confusing problems have been one service failing in a way its own health check couldn’t see, and that’s very hard to find without them.
02 / WORK WITH THE WHOLE TEAM
Your engineer knows the recent change. Support knows what the customer experienced. Bring both into the investigation, alongside the code and telemetry.
Discuss the investigation in Slack or Microsoft Teams. Track the work in Linear. Review the code in GitHub. The findings, decisions, and proposed change stay connected to the original problem.
Explore connected workflows →
Ask questions, add context, and set a review boundary.
View full-size screenshot
Bring alerts, questions, and team context into the conversation.
Work from your channels →
Track production problems as issues. Mention or assign Aient to investigate within the issue.
Aient for Linear →
From the source code to a tested pull request, with review and discussion beside the change.
Explore fix pull requests →Also connected: Email for updates, Telegram for chat, and the Aient web app for the full investigation.
Find an existing investigation, read its progress, and continue the conversation with the Aient CLI.
Explore the CLI ↗Use MCP to query problems, logs, and investigations from the tools you already work in.
Connect through MCP ↗03 / UNDERSTANDING ACCUMULATES
Review the lessons Aient proposes. Approved memory and reusable skills become available to future investigations, with a link back to the work they came from.
One possible lesson from this case: compare the browser’s deadline with when the server actually starts and finishes the request.
Your team can inspect the original investigation, refine the lesson, and approve it for reuse.
Revisit the diagnosis ↑A later loading issue can start with that timing check. Check it against the current code; fresh evidence may lead to a different explanation.
04 / CONNECT THE MISSING CONTEXT
Aient discovers services in your repositories and can propose the code needed to send telemetry. Review the instrumentation pull request, deploy it, and follow its progress in the app.
Connect existing OpenTelemetry ↗Upload source maps with your release so Aient can trace minified browser errors back to the matching source.
Source map setup ↗FROM REPOSITORY TO TELEMETRY
Aient maps selected repositories to the services inside them.
Instrumentation arrives as a pull request for your team to review.
See telemetry status in the app after deployment.
05 / ACCESS AND CONTROL
Decide who joins, what Aient can access, and which changes get approved.
Organisation roles distinguish owners, admins, members, and viewers. Owners manage team roles; admins can invite and manage members and viewers. Review invitations, change roles, and remove access from team settings.
Aient checks identity and applicable permissions before acting on an instruction. Being in a Slack channel does not make someone an investigation’s owner. Linking a channel identity does not, by itself, grant access to the app.
Select the repositories available through the GitHub App and revoke access when needed. Aient proposes code changes as pull requests. Merge automation is off by default; when enabled, it still requires human approval of the exact change and passing checks.
Investigations use the source code and telemetry you make available. Remediation may send relevant context to model and sandbox providers. Review the privacy policy for data use and retention, and the subprocessor list for providers and processing locations.
NEXT / CTO AGENT · IN DEVELOPMENT
We’re building an engineering partner that connects production evidence to your team’s goals. Bring a question about reliability, performance, or a customer journey—and work toward a clear decision about what to do next.
THE QUESTIONS IT’S BEING BUILT FOR
“What deserves our attention this week?”
“Where are customers getting stuck?”
“What changed after we shipped?”
The CTO agent is in development. The investigation workflow shown above is available today.EXPLORE / THE PRODUCT AND THE THINKING
See how the parts work together. Read the engineering decisions behind them.
FROM THE FOUNDER
The gap between an agent that writes code and one that notices what production needs.
Read the story →TRUST & EVIDENCE
What it takes to turn trust in an agent into something you can inspect.
Read the essay →ENGINEERING PRIORITIES
How to decide which problems deserve your engineering time.
Read the essay →YOUR SERVICE. YOUR FIRST INVESTIGATION.
Connect a repository and its production signals. Bring in the people who know the system, and investigate the evidence together.
Get startedPlanning your first connection? Read the setup guide ↗See pricing →