Skip to content
NOFire.ai

Production context for autonomous operations

Services, owners, dependencies and every change, up to date, so each autonomous action starts from the right facts.

Production context graph: every service with criticality, readiness, tier and owner

One entity per service, across realms and clouds

Each deployment of checkout-api shows where the deployment runs, the version and the past incidents, under one entity with one owner.

checkout-api deployments: prod-eu on prod-eu-eks and prod-us on prod-us-gke at 4.18.1, INV-41207 as a past incident in prod-eu, and staging at 4.18.2, marked as different from production

Code, deploys and datastores linked to each service

Each service links to the repository that builds the service, the repository that deploys the service, and the datastores and queues the service runs on.

checkout-api links: built from northwind/checkout-api, deployed from northwind/gitops, and runs on orders-db, checkout-cache, orders.paid and orders-queue, each observed

Dependencies and blast radius

What calls what, read from production traffic. Before an action, the agent sees the blast radius: which callers, datastores and teams a change on this service reaches. Each edge is observed or marked as inferred.

checkout-api depends on payment-gateway, inventory-service and fraud-scorer, and is referenced by api-gateway and cart-web, each link observed

Readiness and compliance checks for each service

Owner, metrics, alerts and resilience per service, checked against the SOC 2 and ISO 27001 controls that apply. You see what would fail an audit, and why.

checkout-api readiness at risk at 75%: owner, metrics and alerts pass, resilience fails as a single point of failure

Context that learns from code, every change and incident

The change timeline lists each deploy, pull request and rollback on the service. The service wiki updates after every change and investigation, and a person approves what is learned.

checkout-api change timeline: v4.18.2 rolled out by Argo CD at 17:25 after PR #2841 cut DB_POOL_MAX from 50 to 10, PR #2857 at 17:38 sets the pool back to 50, and the rollback at 17:41 approved by Maya Chen in Slack

The cost, the risk and the audit

The work to keep a production context graph correct, built in-house or with NOFire AI.

NeedBuild in-houseWith NOFire AI
CollectA collector per tool, maintained as APIs changeConnect once: Kubernetes, clouds, Git, monitoring and tickets
ResolveMatching rules to tell which names are the same service, maintained by handOne entity per service across realms and clouds, each fact observed or inferred
Keep currentA graph that drifts the day updates stopRebuilt from your production environment
RiskAn agent acting on a stale owner or a missed dependencyEvery agent action starts from current facts and passes your policy
ComplianceMapping services to controls and collecting evidence by hand before each auditEach service checked against the SOC 2 and ISO 27001 controls that apply, with the evidence
Cost of ownershipA platform team to build and run the graph, every yearIncluded in the platform

Frequently asked questions.

What is a production context graph?

Every service, owner, dependency, change and readiness check across every realm and region, built from your production environment. People and agents work from the same context.

Do we replace our developer portal?

No. Keep the portal. NOFire AI adds the live layer underneath.

Do we write YAML?

No. NOFire AI builds the graph from your clouds, Kubernetes, code and deploy tools. Each fact is marked as observed or inferred.

What if a fact is wrong?

Each fact shows the source and the time of the last read. A person approves what agents learn before the service wiki changes.

How is this different from Backstage?

Backstage is a portal your team updates by hand. The production context graph is rebuilt from your production environment.

Put AI agents to work on production, safely.