Governed AI-agent orchestration for software delivery

AI agent work, as a controlled delivery process.

Agent Orchestrator turns work items, repos, pull requests, and review feedback into governed AI-agent workflows with human oversight and visible writeback into the tools your teams already use.

Work items · repositories · model runtimes · governed writeback

user-story / 4821ai-enabled
live process
Source work item
ADO · User Story 4821
Fix billing webhook idempotency
Agent Job
orchestrated execution
job/4821-impl
Refinement
done · 1 attempt
Implementation
running · attempt 1
Review
queued
writeback - ADO 4821PR #312 opened
01 - The problem

AI coding tools are powerful. Unmanaged AI usage is a process problem.

A developer pastes context into a local agent, generates changes, and pushes. The organization never sees why it ran, what it used, what it changed, or what still needs approval.

Unmanaged
developer-laptop
  1. 1
    Manual context paste
    no link to work item
  2. 2
    Local agent run
    credentials on device
  3. 3
    Push to branch
    no record of model used
  4. 4
    PR opens
    team has no visibility into AI work
No audit trail. No retries. No writeback.
Governed
agent-orchestrator
visible
  1. 1
    Source work item
    ADO User Story
    ai-enabled
  2. 2
    Agent Job created
    linked to source
    orchestrated
  3. 3
    Bounded phases
    refine -> implement -> review
    running
  4. 4
    Writeback + PR
    visible in ADO + portal
    audited
Every attempt, artifact, and writeback is inspectable.
02 - Core workflow

Source work item, to Agent Job, to writeback. Visible at every step.

portal / billing workspace / user-story / 4821
Fix billing webhook idempotency
ADO · User Story 4821 · assigned to billing-team
ai-enabled
Agent Job · job/4821
linked to source · controlled execution
Refinement
queued
Implementation
queued
Review
queued
PR #312 · agent/4821 -> main
3 files changed · CI green
Writeback to source
status, comments, PR link · audit recorded
stage 01 / 07source

A source work item exists

Every automation starts from a real business-facing item, initially an Azure DevOps User Story. Nothing in the platform happens without one.

scroll to advance · 6 stages remaining

03 - Customer portal

Operate AI work like any other part of delivery.

portal / billing-team workspace / setup

Setup overview

ready
Work item store
Azure DevOps · acme/billing
ok
Repositories
billing-svc · billing-web
ok
Model access
OpenAI default, Anthropic
ok
Routing rules
Area: Billing -> billing-svc
ok
Ingestion
Polling · 30s
live
Process setup
applied to project
ok
view 1 / 4

Setup overview

One place to see the full integration: workspace, work item store, repositories, model access, credentials, routing, and ingestion. Diagnostics tell you what's ready and what isn't.

concept · Episode
The reason automation ran: initial enablement, a comment, a description change, a manual retry, or PR feedback.
04 - Setup

Guided setup turns disconnected systems into a ready operational workspace.

Setup is grouped into plain-language stages. Each step produces an inspectable artifact: a credential reference, routing rule, readiness check, or process setup result.

step 1applied

Connect

Workspace, work item store project, repositories.

  • Create workspace
  • Setup shell
  • Work item store provider
  • Connect project
  • Connect repositories
step 2applied

Configure model access

Your credentials. Your model providers. Stored as references.

  • Choose access approach
  • OpenAI / Codex / Claude Code
  • Default per setup
step 3applied

Route and ingest

Map source work to repositories and choose scheduled or event-driven ingestion.

  • Routing rules
  • Polling and webhooks
  • Provider setup applied
step 4ready

Approve and go live

Bootstrap analysis, readiness checks, then operational overview.

  • Repository bootstrap
  • Readiness analyzed
  • Setup overview

Connect the systems your teams already use, validate access, and launch with an inspectable readiness record.

05 - Governance

Trust without compliance wallpaper.

Four operational pillars. Each one maps to a real surface in the product, not a slogan.

Customer-owned credentials

You bring your model provider keys. The platform stores references and scopes them to setups, not raw secrets pasted into prompts.

in the product
openai · ref:keys/billing-team-default
anthropic · ref:keys/billing-team-claude

Bounded phases

Refinement, implementation, review, review-fix, writeback. Each phase has a known trigger, inputs, attempts, artifacts, and writeback target.

in the product
phase=implementation policy=conservative
max_attempts=3 budget=enforced

Visible attempts

Every run, retry, and failure is recorded with provider, inputs, outputs, and writeback result. The audit trail is the product.

in the product
10:18 · impl · ok · provider:openai
10:34 · review-fix · ok · provider:anthropic

Human controls

Authorized users can retry, cancel, rerun, poll, or repair a phase. Decision points are exposed; nothing important is hidden behind a chat.

in the product
roles · admin · operator · viewer
decision-required -> human episode
06 - Integrations

Connect the delivery systems and model runtimes your teams already use.

Work item stores
Azure DevOps
Boards · User Stories · Tasks
GitHub Issues
Issues · labels · comments
GitLab Issues
Issues · milestones · notes
Repositories
Azure Repos
Pull requests · branches
GitHub
Pull requests · branches
GitLab
Merge requests · discussions
Bitbucket
Pull requests · tasks
Model and runtime providers
OpenAI / Codex
Hosted models · Codex CLI
Anthropic / Claude Code
Anthropic models · Claude Code CLI
OpenAI-compatible endpoints
Customer-controlled model access
OpenCode
Open-source CLI runtime
07 - Deployment and trust

Explicit boundaries across identity, credentials, data, and execution.

self-hosted

Kubernetes deployment

Containerized services and Kubernetes-ready configuration for controlled platform deployment.

isolated

Service isolation

Separate control-plane, provider, runtime, persistence, and portal service boundaries.

runtime

Customer-controlled models

Bring model credentials or connect compatible endpoints without embedding secrets in prompts.

access

Scoped access

Tenant, workspace, setup, and role boundaries constrain configuration and operational actions.

operational controls
  • Customer-owned credentials, scoped to setups
  • Workspace and setup boundaries enforced in product
  • Explicit model and provider configuration
  • Auditable attempts, outputs, PRs, comments, writebacks
  • Human review paths and authorized control actions
  • Polling and authenticated webhook ingestion with replay protection

Bring AI work into the same process you already trust.

Connect your work-item systems, repositories, and model runtimes. Keep every automated step visible and governed.