Should you build your own AI SRE? Build vs. harness vs. closed product

TL;DR

• After an AI SRE demo works, ask what you still need to build, staff, and operate for production incidents.
• Building an agent yourself gives you control, but you must define incident state, connect tools, preserve investigation evidence, set approval boundaries, and record actions for review.
• An open-source harness supplies some execution machinery. AURA, an Apache 2.0 SRE execution harness, runs independently of the Mezmo platform. You still own its configuration and deployment.
• A closed product may supply more of the operating layer, but you still need to verify its boundaries and assign ongoing ownership. This guide compares those responsibilities rather than choosing between open and closed software or scoring vendors.

The question to ask after the demo works

A working demo shows that an AI SRE agent can call a tool and draft an explanation. For production use, you must decide how the agent preserves an investigation across shifts and handles tool timeouts and operator approvals. LangGraph’s documentation describes checkpointing and interruption controls. Those framework features can preserve a run, but you must still define what the agent records about an incident and when a person must intervene.

Define what the agent remembers about each incident and how it recovers from a failed tool call. If a command times out, the agent must establish whether the command changed production before retrying it. You also need to decide which actions require approval, who can approve them, and what record an operator can inspect afterward.

Compare the three approaches by identifying who supplies and maintains six parts of an AI SRE agent. Incident state covers the timeline and current status. Tool integration determines what the agent can read or change. Evidence-backed investigation connects a diagnosis to the observations behind it. Approval boundaries control actions, while auditability preserves a record of decisions and tool calls. Ongoing maintenance covers the work of keeping those pieces current as your tools and policies change.

Building from scratch: what you take on

Building from scratch gives you control over the incident workflow, but a general-purpose framework leaves the production rules to you. LangGraph, CrewAI, OpenAI Agents SDK, and Claude Agent SDK offer different ways to coordinate agent work. Check the documentation for each framework or SDK to establish which state, tracing, and approval features it supplies. You must still define what an incident record contains and which actions the agent may take.

Incident state needs to survive interruptions and remain useful to the next person on call. You might record the affected service, observations, hypotheses, tool results, action requests, and human decisions. LangGraph can save state and pause a run before a step, but you must define the approval policy, identify authorized approvers, and decide what happens when nobody responds. If a tool call fails halfway through an investigation, you must also decide whether the agent can retry it safely or needs a person to intervene.

Tool access and evidence require separate design work. You must connect monitoring and production tools, scope their permissions, and specify how the agent handles timeouts and repeated calls. A retry that repeats a read differs from one that repeats a production change. OpenAI Agents SDK can trace tool calls, but you must preserve which observation supports each diagnosis, when the agent collected it, and whether later evidence changed the conclusion. You also need an audit record that ties approvals and actions to the incident, rather than relying on a trace of agent steps alone.

Building from scratch can make sense if you have platform engineers who can maintain that code and need control over its behavior. The ongoing commitment includes updating integrations when tools change, testing failure paths, and keeping approval and audit rules current.

Adopting an open-source production harness

An open-source production harness gives you a starting point for running an AI SRE agent, but you still own its configuration and operation. AURA is an Apache 2.0 SRE execution harness that Mezmo built to help SRE teams manage production environments. AURA is an SRE Agent for Production: an autonomous execution harness and first responder designed to investigate and remediate production incidents through configured tools and approval rules. AURA can run on your infrastructure without the Mezmo platform, letting you bring your models and connect your stack.

AURA provides a configurable execution layer for incident work. Its documentation describes agent behavior and tool access. Verify the state and configuration capabilities you need against the current documentation. For tool access, AURA connects to existing services through MCP, a standard way for an agent to call external tools. You still choose which tools the agent can reach, provide the connections, and set the permissions and network rules around them.

For evidence-backed investigation, check which knowledge sources the AURA documentation currently supports and how the agent uses them. You decide which records and instructions the agent can use, and you must keep those sources useful for production investigations. AURA’s documentation also describes human approval gates for configured tool calls. Check the approval documentation for how denied requests, timeouts, and approval-service failures affect execution before granting production write access. You write the approval policy and manage the credentials and access controls that enforce it.

Check AURA’s documentation for the telemetry it emits and the records available for review. You will need to decide where to collect those records and whether they satisfy your incident audit requirements. You still operate the record-storage system you choose and maintain the harness deployment, secrets, configuration, and tool connections. Adopting AURA replaces some harness-building work with configuration and ongoing operational ownership.

Buying a closed product

A closed AI SRE product supplies investigation software that you do not have to build from scratch. Before buying, establish which incident-state, integration, approval, and audit functions the supplier maintains. A product demonstration can show how those functions behave, while documentation and contract terms establish who owns them after deployment.

NeuBird says its agent uses permissioned data connections and describes an investigation process that gathers more data as it tests hypotheses. NeuBird also describes engineer approval for actions and a full audit trail. Those statements are vendor claims, not independently verified specifications. The cited post does not establish where NeuBird stores incident state or how its approval workflow handles exceptions; ask NeuBird to demonstrate both.

You still need to connect a closed product to your data sources, map its access to your permissions, and define which actions require approval. The product may provide controls for these tasks, but you set the policy and grant the access. Ask the supplier to show one investigation end to end, including the evidence behind its conclusion, the approval record, and what happens when a connection fails. Ask who maintains integrations and how you can retrieve incident records if you leave. Thin documentation calls for direct questions, not assumptions that a capability is present or absent.

Decision table: what each path supplies and what you own

Compare what each path supplies with what you must still build or operate. The open-source column uses AURA as a documented example, not as a stand-in for every harness. AURA’s documentation describes its controls. NeuBird’s account makes vendor claims about one closed product, so undocumented details remain open questions. For the build-from-scratch column, verify each framework’s features in its own documentation.

Choose the path whose remaining work your staff can operate and maintain after the demo.

Matching the approach to your team's constraints

A build-from-scratch approach fits when you have platform engineering capacity to maintain an agent after the prototype works and need control over its incident model or execution logic. A general-purpose framework can provide useful building blocks, but you still define how the agent preserves incident state, connects to your tools, records evidence, and handles failed actions. Choose this path when those decisions warrant custom engineering and you can staff that work over time.

An open-source harness fits when you want to inspect or modify the execution layer without building every operating mechanism yourself. For example, AURA is an Apache 2.0 SRE execution harness that runs independently of the Mezmo platform. Its documentation describes tool connections, approval gates, state handling, and a choice of models. You still own the configuration, credentials, deployment, and policies that determine what the agent may do in your environment.

A closed product fits when you prefer to evaluate a supplied application rather than maintain the execution code. Check whether its documented incident state, evidence trail, approval controls, and tool connections meet your requirements before treating those responsibilities as covered. Compare the supplier’s procurement and deployment timeline with the engineering and maintenance work the other routes leave you.

Before granting production write access, test how your chosen approach handles interruptions, unavailable tools, and approval requests.  Those tests reveal which responsibilities the approach supplies and which your team must operate.

FAQs

Can you start with a harness and add governance later? Yes. You can extend governance over time, but define and test approval requirements before granting an agent production write access. AURA supports configurable approval gates, so you can begin with a narrow set of permitted actions and revise those rules as you learn. Adding a gate later will not create an audit record for earlier actions.

What does evidence-backed investigation require? Evidence-backed investigation requires records you can inspect that connect each diagnosis to the observations behind it. For example, you should be able to compare a suspected deployment with the service’s error data and deployment history. Model reasoning alone does not establish that the deployment caused the errors.

Does open source remove the maintenance burden? No. An open-source harness can supply execution mechanics, but you still own its deployment, configuration, credentials, and updates. AURA’s repository makes its implementation available to inspect and modify. You still need someone to operate it.

What happens to incident state if you switch tools or models? A model change and an incident-state migration are separate decisions. Before switching, check where the harness stores incident context, which records survive a configuration change, and whether a replacement tool can read the evidence your earlier investigations used.

Conclusion

Choose the approach whose ongoing responsibilities you can support. Before committing, identify who will maintain tool connections, review approval rules, and trace an investigation when its evidence is disputed. Test whether you can inspect the resulting records and maintain those controls over time.

If you want to examine a working harness before deciding, AURA’s GitHub repository offers a place to inspect the code and assess what you would still need to maintain.