Last Tuesday, at 2 AM, our staging environment went down. Again. I got the PagerDuty alert, dragged myself out of bed, and spent 45 minutes SSHing into boxes, digging through logs, and restarting services—only to find out a junior dev had pushed a misconfigured Docker Compose file. I realized then that my team needed a better way to handle routine infrastructure diagnostics. Manually running the same five checks every time something breaks is a waste of human brainpower.
That's what led me to experiment with the OpenAI Agent Platform for DevOps. I wanted to see if I could build an agent that could handle that initial triage—checking service status, pulling recent logs, and giving me a summary before I even open my laptop. Here's how I actually got it working, including the parts where I stumbled.
Setting Up the Foundation
The OpenAI Agent Platform is essentially a suite of APIs, an SDK, and a visual builder designed to create agentic workflows—applications where the LLM can reason, use tools, and take actions rather than just generate text.
I started with the Agents SDK quickstart. You need Python installed, which is standard for any DevOps toolchain these days. First, I set up a virtual environment and installed the SDK:
python -m venv devops-agent
source devops-agent/bin/activate
pip install openai-agents
Next, I had to set up my OpenAI API key. I made the rookie mistake of just hardcoding it into my test script. Don't do that. Use an environment variable:
export OPENAI_API_KEY="sk-your-key-here"
I added this to my .zshrc so it persists, but for production, you'll want to use a secrets manager like AWS Secrets Manager or HashiCorp Vault.
Building the First Agent: The Infrastructure Triage Bot
I decided to start small. My first goal wasn't to build an agent that could autonomously fix production issues—that's a recipe for a resume-generating event. I just wanted an agent that could run my standard diagnostic commands and summarize the results.
Here's the basic Python script I wrote to define the agent:
from agents import Agent, Runner
# Define the tools our agent can use
def check_service_status(service_name: str) -> str:
"""Check if a systemd service is active."""
import subprocess
result = subprocess.run(
["systemctl", "is-active", service_name],
capture_output=True, text=True
)
return f"Service {service_name} status: {result.stdout.strip()}"
def get_recent_logs(service_name: str, lines: int = 50) -> str:
"""Pull recent journalctl logs for a service."""
import subprocess
result = subprocess.run(
["journalctl", "-u", service_name, "-n", str(lines), "--no-pager"],
capture_output=True, text=True
)
return result.stdout[-2000:] # Truncate to avoid token limits
# Create the agent
triage_agent = Agent(
name="DevOps Triage Agent",
instructions="""You are a DevOps triage assistant. When alerted about a service issue:
1. Check the service status using check_service_status
2. Pull recent logs using get_recent_logs
3. Summarize the likely root cause based on the logs
4. Suggest immediate remediation steps
Be concise and focus on actionable information.""",
tools=[check_service_status, get_recent_logs]
)
# Run the agent
result = Runner.run_sync(triage_agent, "The nginx service on staging seems to be down. Can you check?")
print(result.final_output)
When I first ran this, I got an error because I hadn't properly decorated the tool functions with type hints. The SDK needs those type hints to understand what parameters to pass. Once I added -> str and typed the parameters, it worked.
The output was surprisingly useful:
I've checked the nginx service on staging:
**Status:** inactive (dead)
**Log Analysis:** The last 50 log lines show nginx failed to start after a configuration reload at 01:45 UTC. The error is: "emerg] 1#1: host not found in upstream "api-server.internal" in /etc/nginx/conf.d/upstream.conf:3"
**Root Cause:** The upstream configuration references a DNS entry (api-server.internal) that cannot be resolved. This likely means the upstream service was decommissioned or the DNS record was accidentally deleted.
**Suggested Remediation:**
1. Verify the DNS record for api-server.internal exists
2. If the upstream is no longer needed, remove it from upstream.conf
3. Test config with `nginx -t` before reloading
4. Reload nginx with `systemctl reload nginx`
That's exactly the kind of triage I'd do manually at 2 AM, but the agent did it in about 8 seconds.
Moving to the Visual Builder
Once I had the basic agent working in code, I wanted to explore the Agent Builder—the visual tool for creating agentic workflows. It lets you drag and drop nodes, connect tools, and publish workflows.
I'll be honest: I was skeptical of the drag-and-drop approach. As a DevOps engineer, I live in YAML and code. But for building multi-step workflows, the visual builder actually helped me see the logic flow better.
I created a workflow that looks like this:
- Trigger Node — Receives a webhook from PagerDuty
- Parse Alert Node — Extracts the service name and environment
- Diagnostic Node — Runs my triage agent
- Slack Notification Node — Posts the summary to our #incidents channel
The visual builder connects these nodes with lines showing data flow. Each node can be configured with specific parameters. For the diagnostic node, I pointed it to the agent I'd already defined in code.
One surprise: the Agent Builder has a feature called ChatKit that lets you publish your workflow as a chat interface. My team can now just type /triage nginx-staging in Slack, and the whole workflow kicks off. That was a nice touch I didn't expect.
Adding Safety Guardrails
Here's where I made my biggest mistake. I got ambitious and added a tool that could restart services. I figured, "Why not let the agent fix the problem too?" I gave it a restart_service function and told it to restart services if the logs clearly indicated a transient failure.
The first time I tested it, the agent restarted three services in quick succession because it interpreted some normal log noise as failures. On my local test environment, this was fine. But it made me realize how dangerous autonomous actions can be in production.
I rolled back and implemented a human-in-the-loop pattern instead:
def restart_service(service_name: str) -> str:
"""Request a service restart. Requires human approval."""
# In production, this would post to a Slack channel and wait for approval
# For now, just return the command that would be run
return f"Proposed action: systemctl restart {service_name} (AWAITING APPROVAL)"
Now the agent suggests actions but doesn't execute them. A human has to click "Approve" in Slack before anything actually runs. This is the right approach for DevOps—agents should inform and assist, not autonomously take down production.
Practical Tips and Honest Limitations
After a few weeks of using this setup, here's what I've learned:
Start with read-only tools. Your first agents should only observe and report. Add write/execute capabilities only after you trust the agent's judgment, and always with human approval gates.
Watch your token usage. Log output can be massive. I truncate logs to 2000 characters in my tools, but even then, a complex triage run costs about $0.05-0.10 in API calls. That adds up if you're running hundreds of alerts a day.
The visual builder is good for simple workflows, but code is better for complex logic. Once my workflow got past four nodes, I found it easier to just write Python. The visual builder is great for prototyping and for team members who aren't comfortable with code.
Latency is a real concern. The agent takes 5-10 seconds to run its full diagnostic cycle. For a 2 AM alert, that's fine. For real-time monitoring, it's too slow. Don't try to replace your existing alerting system—augment it.
The SDK is still evolving. I ran into a few breaking changes when updating the package. Pin your versions and test thoroughly before updating.
The OpenAI Agent Platform isn't going to replace your DevOps team. But it's genuinely useful for automating the repetitive diagnostic work that eats up your on-call shifts. My staging triage agent has saved me from at least three late-night SSH sessions this month, and that alone makes it worth the setup time.