Skip to main content
Use the Python API when your code runs on the same machine as OpenSRE and you want agent responses without invoking the CLI. For network access, use the HTTP API. To supply your own output sink, tools, prompts, or error reporting and drive one agent across many turns, see Hosting the Agent.

OpenSRE as a teammate in your daily loop

OpenSRE functions as an autonomous engineering teammate embedded directly into your daily operational workflows. Rather than treating the agent as an isolated chat interface, you can embed the Python API into scheduled cron jobs, CI/CD pipelines, and automated incident triage loops to perform recurring tasks — auditing repository health, triaging production alerts, and delivering digests to team channels like Slack, webhooks, or ticketing systems.

Prerequisites

The standalone CLI installer does not provide an importable package. Install from a source checkout:
Configure a provider once (opensre onboard) — the session API reuses the same config and credentials as the CLI. Run your script inside the checkout’s environment with uv run python your_script.py. Register adapters before the first turn (tools and investigation):

Daily engineering recipes

Recipe 1: Querying repository and workflow metrics

Use session.chat() to query configured developer tools and observability sources (e.g. GitHub star velocity, PR backlog, deployment status):

Recipe 2: Automated alert triage and root-cause analysis

Use session.investigate() to pass a raw alert payload from your alertmanager, webhook, or monitoring system directly into OpenSRE’s investigation pipeline:

One API — chat and investigate

Every surface uses the same two verbs:
Or the one-liner that wires the same boot step for you:
AgentSession.start() resolves the environment, opens a session, and attaches an agent with the standard ports — the same tools and prompts the interactive shell uses. It does not register adapters (core may not import bootstrap); call configure_process first or use start_embedded_session. investigate does not require an attached chat agent; pass it the run_investigation_payload runner as shown above (core may not import tools, so the caller supplies it). Always verify turn success before trusting chat text:
  • For conversational questions and digests, the agent synthesizes an answer (result.answered).
  • For action-only turns (tools handled the request directly without an LLM call), verify result.action_result.handled with not result.action_result.has_unhandled_clause and result.action_result.accounting_status == "completed".
  • When a turn fails (for example the LLM provider is unreachable) or is cancelled (result.cancelled), the failure details land in result.primary_response_text.

Internal seams (not for hosts)

Chat hosts terminate at dispatch_chat_turnrun_turn. Investigation terminates at the payload runner the caller passes to investigate (run_investigation_payload). Do not invent parallel public entrypoints.

Unattended daily delivery and background loops

For recurring daily workflows (such as scheduled morning digests or CI health checks), start an in-process session with live gathering enabled to query active integrations and forward findings to team channels:
In the interactive shell, asynchronous investigations and automated notifications are managed via /background:
  • /background on enables async background investigation launches.
  • /background notify set telegram (or email, rocketchat, buzz) routes completed RCA reports directly to your team’s notification channels upon task completion.
  • /background show <task_id> inspects delivery status and findings.

A conversation

Each chat call is one turn in the same session, so follow-ups see earlier context:
To resume an existing session, pass its ID:

Run until a goal is complete

Use chat_until_goal when one request may need several agent turns. Pass an explicit SessionGoal so the completion condition, checklist, and turn limit do not depend on the first turn inferring them:
The loop stops when the goal is achieved, paused, cancelled, cleared, or its turn budget is exhausted. The result contains the final goal, the last_result from chat, and turn_count. Without goal=, the first action turn must attach a goal; otherwise chat_until_goal returns after that one turn. Use cancel_requested to stop between turns and on_progress to receive checklist updates.

Custom grounding context

By default, the agent builds prompts from the session. To supply a custom system prompt or retrieved context, pass a provider:
If omitted, core.agent_harness.spi.defaults.DefaultPromptContextProvider is used. A custom provider must implement core.agent_harness.ports.PromptContextProvider. The same prompts= argument is accepted by DefaultHeadlessBuild.agent() on the custom-ports path below.

Custom output and ports

start() buffers all output. To capture tool progress yourself (for example to stream to a websocket), build the agent and pass your own sink:
Any object implementing the OutputSink protocol (core.agent_harness.ports.OutputSink: print, render_response_header, render_error, stream) may replace BufferOutputSink. DefaultHeadlessBuild also takes a custom logger, console, and prompt surface; its agent() takes your own tool provider (tools=, usually a configured DefaultToolProvider) and gather ports — see its docstring.

External tools

Register a package before the first tool lookup:
Requirements:
  1. Declare tools with surfaces=("action",) (or include "action"). The @tool default is ("investigation",) only; the chat and Python API action loop does not load investigation-only tools.
  2. Tools may be defined in the package __init__.py or in submodules; both are discovered after registration.