Symphony / Agents

DevOps agent for controlled operations

A Slack-first DevOps agent should take control of jobs through typed runbooks, policy gates, and an auditable operations ledger. It should not become a chat-shaped production shell.

Surface SlackOrchestrator SymphonyRunner typed runbooksGate approval policy
Slack request→Plan hash→Approval→Runbook→Evidence report

Operating model

Give the agent control of jobs, not unchecked control of infrastructure.

The right design keeps Slack as the human command surface, Symphony as the planner and runner, existing provider APIs as the execution boundary, and the database as the durable memory of every operation.

<3s
Slack acknowledgement target
Always ack fast, then work async.
1
Production lock
Only one deploy-class run at a time.
5
Capability levels
Read-only through break-glass control.
0
Raw shell by default
All actions route through typed tools.
01

Slack command surface

Interactive entry

Slack should start every operation with a structured intent. The agent replies with a plan, risk classification, and visible next action instead of silently running a job.

$/ac-devops promote staging to production
L3 production changeRequires an authorized approver outside the initiating identity for production.

Replaces the existing script with a conversational planning and approval wrapper.

  • Submodule SHA diff and release manifest preview
  • Migration plan and rollback boundaries
  • Approval card with plan hash, TTL, and affected services
02

System architecture

Control plane
SlackSlash commands + buttonsSlack ingressAck, verify, enqueuePolicy gateRisk, identity, allowlistLinearWorkpad + audit linkSymphony DevOpsPlanner + runbook runnerOps ledgerRuns, steps, locksGitHubActions + refsSupabaseMigrations firstHerokuBuilds + releasesSentryRelease healthProductionFrontend, API, DB
03

Capability policy

Guardrails

L3

Production change

The agent can deploy or rollback production through approved runbooks.

ApprovalTwo-party approval for high-risk actions, with plan hash and TTL.
Credential scopeShort-lived production credentials minted per run.
04

Runbook library

Typed execution

The agent earns trust by shrinking each operation into a named, typed runbook. Natural language chooses the runbook and fills inputs, but the mutation still happens through deterministic steps.

promote

Promote to production

Inputs
  • source branch or release tag
  • target services
  • migration mode
Guarded actions
  • acquire production lock
  • verify clean staging state
  • run existing promotion script as an owned step
Outputs
  • release manifest
  • provider release IDs
  • Slack completion report
05

Production promotion flow

Existing script wrapper
promotion/run-4381locked: production

Build the immutable plan

Read submodule refs, provider state, pending migrations, and release notes. Store a plan hash before any approval.

Evidencesubmodule diff, workflow readiness, migration preview
  1. Planactive checkpoint
  2. Approverecorded
  3. Databaserecorded
  4. Appsrecorded
  5. Verifyrecorded
  6. Reportrecorded
06

Operation ledger

Audit memory

A DevOps agent needs its own ledger because Slack history and provider logs are not enough. The ledger lets Symphony resume, audit, lock, and explain every operation after the conversation has moved on.

SQL table

devops_runs

One row per agent operation, including requester, command, plan hash, status, and final result.

idrisk_levelrequested_byplan_hashstatuscreated_at
07

Infrastructure rollout

Adoption path
0

Inventory current DevOps jobs

Wrap the promote-to-production script and list every provider token, manual step, and rollback assumption.

1

Ship read-only Slack commands

Start with status, release history, locks, workflow logs, and Sentry release summaries.

2

Add dry-run planning

Generate promotion and rollback plans with plan hashes, evidence links, and no mutations.

3

Run staging jobs

Allow reversible non-production actions to test the ledger, policy gate, and Slack interaction loop.

4

Gate production promotion

Move existing promotion behind approvals, locks, short-lived credentials, and health verification.

5

Expand to controlled operations

Add rollback, drift reconciliation, scheduled audits, and incident mitigations after promotion is boring.

08

Research sources

References
Slack slash commands and interactivityapi.slack.com/interactivity/slash-commandsSlack Socket Modeapi.slack.com/apis/socket-modeGitHub Actions workflow dispatchdocs.github.com/en/rest/actions/workflows#create-a-workflow-dispatch-eventHeroku Platform API releasesdevcenter.heroku.com/articles/platform-api-reference#releaseSupabase CLI migrationssupabase.com/docs/guides/local-development/overviewOpenAI Agents SDK guardrailsopenai.github.io/openai-agents-python/guardrails/