An autonomous agent organization that lives in your cloud

• Azure-native
• Deterministic-first
• Observe first, then enable changes
• Every action audited
• Human-in-the-loop on high risk

One workload, from first commit to production

Follow a single workload through its life. The same agent organization is present the whole way - reviewing while you build, reviewing itself at the handoff, and running the control loop once it is live. You stay in the loop through the channel you already use, and you are asked for approvals, not toil.

1 While you build

The org is watching before you ship

From the first pull request and the first resource, the organization reviews every change against your security, cost, and reliability rules. Heimdall watches drift, Huginn correlates the signals, Mimir checks each change against the catalog, Njord prices the impact - and Bragi reaches you in the channel you already live in. A nudge in Teams or Slack before it becomes an incident, not a 3 AM page after.

Heimdallposted to #cloud-ops - Teams / Slack

Heads up: the new payments-api managed identity requests Owner on the resource group. Least privilege needs Contributor plus two data-plane roles.

securitycostreliability

Caught at PR time. A proposed fix is attached in observation mode - nothing changes until you say so.

2 At the handoff

The dev-to-ops review runs itself

When the workload is ready to become the operations team’s responsibility, an ownership-transfer signal triggers the Operational Readiness Review. The org evaluates the whole scope’s accumulated posture - not one diff - across policy, identity and RBAC, reliability, and dependency ordering. Forseti makes the decision; Njord, Freyr, and Loki advise; Saga writes the audit and the report. You are asked for one thing: an approval. The report is generated for you.

Operational Readiness Reviewneeds_review

• policy_guardrailclear
• identity_rbac1 detected issue
• reliabilityclear
• dependency_orderingclear

Forseti judgesNjord / Freyr / Loki adviseSaga audits

Approve handoffauto-generated ReadinessReport attached

3 In production

Then it just lives in your cloud

Once it is yours to run, the same organization runs the control loop continuously. Deterministic-first, governed by safety checks, observation-first: most events resolve without a model, Thor executes the safe majority, Vidar owns rollback and DR failover, and every decision - including the no-ops - is audited. You approve the high-risk few through Var; the organization handles the rest and reports back. Here is the loop it runs on every event.

How Forward Deployed Agents resolve events

One control loop, from signal to audit. Every event is normalised, routed by confidence, and gated by risk - and language models are reserved for the ambiguous few that the deterministic tiers deliberately defer.

1. 01

   Ingest

   Normalise, dedup, and correlate raw events into incidents.

2. 02

   Route

   The trust router scores confidence and picks the cheapest tier: T0, T1, or T2.

3. 03

   Check

   The safety check routes to automatic action, human approval, or denial; T2 first clears the quality check.

4. 04

   Execute

   The executor applies the change with a stop-condition, rollback, and impact-scope limit.

5. 05

   Audit

   Every decision - including no-ops - is appended to the immutable audit log.

How the tiers split the load Route by confidence: the cheapest tier that can resolve an event, does. Most events never reach a model.

100 events in

1. T0 Deterministic rules - policies - checklists
   78 %
2. T1 Lightweight reuse embedding similarity - small classifiers
   17 %
3. T2 Reasoning mixed-model - verifier - evidence check
   5 %

Design targets, not measured results - Forward Deployed Agents never claims a number without a paired baseline measurement.

What autonomy earns you

• ↳ ~70-80% of events resolved deterministically. Rules, policies, and checklists decide the repeatable majority. No model call.

• ↳ ~15-20% resolved by lightweight pattern reuse (T1). Embedding similarity to past resolved incidents, small classifiers, no frontier model.

• ↳ Only ~5-10% reach the reasoning tier (T2). Mixed-model cross-check plus deterministic verifier - the model proposes, the verifier disposes.

• ↳ Every autonomous action carries four invariants. Stop-condition · rollback path · impact-scope limit · audit-log entry. Missing any of the four ⇒ the action requires human approval, not automatic execution.

• ↳ New capabilities start in observation mode, never as a surprise. Enabling changes is a separate, measurable gate against the Phase 0 baseline.

• ↳ All figures above are design targets, not measured results. Forward Deployed Agents never claim a multiplier without a paired baseline measurement.

One core, three domains

Each domain shares the same event-driven, risk-gated core; they differ only in the rules and actions they load.

Change Safety · Phase 1

Rule catalog, T0 policy gate, fix PRs. The change check starts in observation mode, then enables changes.

Resilience · Phase 3

Scheduled resilience testing, DB DR drills, impact-scope-bounded chaos experiments - always with a stop-condition and rollback path.

Cost Governance · Phase 3

Cost anomaly detection, right-sizing PRs, budget guardrails per resource group. Automatic execution or human approval follows the risk classification.

Meet the agent organization

Fifteen named agents run the control plane as a single organization - each owns a role and hands off through a schema-checked event bus. It is an org chart, not a metaphor: the judge never executes, and every action is initiated, judged, approved, executed, and audited by distinct agents.

Odin - command

The master planner. Cross-vertical arbitration and the final tie-break before a decision is finalised.

Judgment and execution

Forseti judges (automatic execution / human approval / denial), Thor dispatches and executes, Var carries the human approval, Vidar owns rollback and DR failover. No agent both judges and executes.

Sensing

Huginn collects and correlates events; Heimdall watches health and drift. Deterministic-first - never an LLM in the hot path.

Conversation and audit

Bragi translates operator questions into tool calls; Saga writes the append-only audit trail and escalates handoffs.

Governance

Mimir owns the rule catalog, Norns learns from outcomes, Muninn holds long-term memory.

Domain specialists

Njord (cost), Freyr (capacity), and Loki (chaos) advise the judge with domain analysis - they never execute directly.

The action ontology

Explore the action ontology Every autonomous change is one typed ActionType entry. Pick one to see the axes the safety check reads before it runs.

Filter by rollback All pr_revert state_forward_only snapshot_restore pitr

• tag-add tag
• disable-public-access disable
• rotate-secret rotate
• remove-orphan-resource delete
• enable-purge-protection enable !
• right-size scale
• restrict-network-access update
• enable-encryption enable
• set-tls-policy update

remediate.tag-add

Category

remediation

Operation

tag

Trigger

rule_violation

Execution path

pr_native

Rollback

pr_revert

Impact scope

1 resource

Default mode

shadow

Attach required tags (owner, cost-center, environment) when they are missing. Control-plane only; safe idempotent rewrite; PR-native rollback undoes the tag mutation.

remediate.disable-public-access

Category

remediation

Operation

disable

Trigger

rule_violation

Execution path

pr_native

Rollback

state_forward_only

Impact scope

<= 5 resources (graph-derived)

Default mode

shadow

Turn off unauthenticated public access on a resource without deleting it. Reverses via a paired enable-public-access action registered through governance - no destructive undo.

remediate.rotate-secret

Category

remediation

Operation

rotate

Trigger

rule_violation

Execution path

pr_native

Rollback

snapshot_restore

Impact scope

<= 20 resources (graph-derived)

Default mode

shadow

Rotate a secret / certificate held in a secret-store. Cross-resource because every depends_on consumer must pick up the new version; the executor coordinates locks per consumer. Rollback pins the prior version.

remediate.remove-orphan-resource

Category

remediation

Operation

delete

Trigger

rule_violation

Execution path

pr_native

Rollback

pitr

Impact scope

1 resource

Default mode

shadow

Delete a resource proven orphaned (unattached disk, unassociated public IP). Fires only when attached_to and depends_on are both absent. Rollback uses the provider PITR / soft-delete window; if it has expired the safety check requires human approval.

remediate.enable-purge-protection

irreversible - human approval required

Category

remediation

Operation

enable

Trigger

rule_violation

Execution path

pr_native

Rollback

state_forward_only

Impact scope

1 resource

Default mode

shadow

Turn on purge protection on a secret-store. Irreversible: once on, the provider does not allow turning it off. The safety check requires human approval and quorum until the promotion gate is measured on the frozen scenario set.

remediate.right-size

Category

remediation

Operation

scale

Trigger

rule_violation

Execution path

pr_native

Rollback

pr_revert

Impact scope

<= 10 resources (graph-derived)

Default mode

shadow

Adjust compute count or SKU to match observed utilization (Cost Governance). Non-destructive; rollback is a PR to the prior spec. Runs after observation mode only after the scenario set proves it never degrades a dependent.

remediate.restrict-network-access

Category

remediation

Operation

update

Trigger

rule_violation

Execution path

pr_native

Rollback

state_forward_only

Impact scope

<= 15 resources (graph-derived)

Default mode

shadow

Tighten network access - remove wide inbound NSG rules (SSH/RDP from any), require a private endpoint, disable public network access. Asymmetric rollback: widening back to any-source is a separate governance-gated action.

remediate.enable-encryption

Category

remediation

Operation

enable

Trigger

rule_violation

Execution path

pr_native

Rollback

state_forward_only

Impact scope

1 resource

Default mode

shadow

Turn on data-at-rest / in-transit encryption on a resource. Forward-only: once encryption is enabled, disabling it is a separate governance-gated ActionType - this one never turns it off.

remediate.set-tls-policy

Category

remediation

Operation

update

Trigger

rule_violation

Execution path

pr_native

Rollback

pr_revert

Impact scope

1 resource

Default mode

shadow

Raise the TLS floor on a resource (min TLS version, HTTPS-only) by updating the IaC-declared property. Rollback via PR revert since the setting is a declarative property.

Every action carries all four: stop-condition, rollback path, impact-scope limit, audit-log entry.

Showing the shipped fix catalog (rule-fired, PR-native, observation-first). The ontology also spans ops and governance categories in the spec.

Delivery phases

Sequential by design - each phase builds on the one before it. Read the reference docs first, then follow the phases in order.

1. Phase 0
   Instrument & unblock

   KPI dashboard, baseline report, identity and policy blockers resolved.

   Exit: reproducible baseline exists.

2. Phase 1
   Rule catalog & T0

   Rule catalog normalised, T0 policy gate live, fix PRs generated automatically.

   Exit: the change check runs in observation mode across the target scope.

3. Phase 2
   Quality gate & T1

   Continuous rule update, LLM quality gate with mixed-model cross-check, embedding-based pattern reuse (T1).

   Exit: auto-resolution rate validated vs the Phase 0 baseline.

4. Phase 3
   Integrated autonomy

   Unified control loop, DR/Chaos scheduler with DB DR drills, FinOps auto-actions with risk-gated approvals.

   Exit: autonomous MVP across all three domains.

5. Phase 4 · TBD
   Scale

   Continuous measurement, pattern-library growth, model cost/quality tracking, scalability. Multi-cloud expansion is TBD.

Ready to put the org to work?

Deploy the agent organization into your own Azure environment, start every action in observation mode, and enable changes once the numbers hold.

Get startedRead the roadmapView on GitHub

Scope reminder

This repo is generic and customer-agnostic. Everything is parameterised; per-customer values live in a fork. Azure is the only implemented target - non-Azure providers and Phase 4 multi-cloud expansion are TBD.