Build your own agent on a platform made to be driven by one.

From the dashboard, create a personal access token, choose the narrow set of scopes the agent requires — for a read-only triage bot, that might be just reading incidents, logs, and the context graph — and attach a daily mutation and data limit. For a bot that will also acknowledge incidents, add that one write scope and nothing else. The guiding rule: grant the smallest set that lets the agent do its job, because that set is the worst case if the token ever leaks.

# Every call is bearer-authenticated against the public API.
export OBSERVE_TOKEN="obs_…"            # from your secret manager, never source
export OBSERVE_API="https://api.24observe.com"

curl -s "$OBSERVE_API/api/v1/incidents?status=open" \
  -H "authorization: Bearer $OBSERVE_TOKEN"

Two things to notice. The response includes headers telling you how much of the token’s daily budget remains and when it resets, so your agent can pace itself without spending a request to check. And the token can only ever do what its scopes allow — the dangerous actions (disabling detections, deleting data, reading stored secrets) are off-limits to any token, so least-privilege is a floor the platform enforces, not just a habit you maintain.

import os, uuid, requests

API = os.environ["OBSERVE_API"]; TOK = os.environ["OBSERVE_TOKEN"]
H = {"authorization": f"Bearer {TOK}"}

# OBSERVE — pull what needs attention
incidents = requests.get(f"{API}/api/v1/incidents?status=open", headers=H).json()

for inc in incidents:
    # REASON — gather evidence with read-only tools, let your model decide
    logs = requests.get(f"{API}/api/v1/logs/search",
                        params={"q": inc["title"], "hours": 1}, headers=H).json()
    decision = my_model.decide(inc, logs)   # your reasoning step

    # ACT — idempotent + scoped; a retry with the same key never double-acts
    if decision.acknowledge:
        requests.post(f"{API}/api/v1/incidents/{inc['id']}/ack",
                      headers={**H, "Idempotency-Key": f"ack-{inc['id']}"})

The two habits that make this production-grade are visible in those few lines. Idempotency: every mutating call carries an Idempotency-Key, so when the agent retries after a timeout — and it will — it cannot create duplicates; retrying the same key is a no-op, and reusing a key with a different body returns a clear conflict so a buggy loop surfaces immediately. Budget awareness: the agent reads its remaining daily allowance off the response headers and slows down as it approaches the cap, rather than slamming into it. Together with a scoped token, that is the whole safety story: bounded permissions, bounded volume, safe retries, full attribution.

Start read-only. Give your first agent a token that can only read — incidents, logs, metrics, the context graph — and let it do nothing but observe and explain. Have it summarise new incidents into your chat, post a digest of overnight activity, or answer questions about what happened. There is no blast radius to worry about because it cannot change anything, so you can let it run wide and watch how it reasons. This stage alone is genuinely useful, and it tells you whether the agent’s judgement is sound before that judgement can touch anything.

Add the safe writes. Once you trust its reading, grant the low-risk actions: acknowledging an incident it has triaged, posting an update, adding a note to a case. These are reversible, low-stakes, and high-value — they take the busywork off your humans without putting anything at risk. Keep the scope to exactly these actions and the daily cap conservative; you can always widen it. Watch the audit log for a week and you will quickly see whether the agent acts the way you would.

Approach the consequential actions carefully — or not at all. Provisioning monitors from a deploy pipeline is a natural next grant because it is bounded and predictable. The genuinely consequential moves — anything that changes production behaviour — are deliberately kept as human-approved proposals rather than autonomous actions, and most teams are happy to leave them there. The lesson from everyone who has built ops automation is the same: the value is overwhelmingly in the investigation and the safe, reversible actions, and the risk is overwhelmingly in the irreversible ones. You can capture almost all of the value while taking almost none of the risk, simply by being deliberate about where on that line each token sits.

Throughout, the platform is on your side. Scopes cap what each agent can reach, daily limits cap how much it can do, the hard guardrails make the truly dangerous actions impossible for any token, idempotency keeps retries safe, and the audit log records every move for review. You are never trusting the agent blindly — you are trusting it within a box whose walls you set and the platform enforces. That is what makes building on 24Observe feel less like handing over the keys and more like hiring a junior who can only reach what you have shown them.