Quick answer
Platform and DevOps teams use Nori to move repeatable work off the on-call engineer. Requests in Slack become reviewed pull requests. Cron schedules run dependency upgrades, flaky-test triage and drift checks overnight. Webhooks turn a failed pipeline into a proposed fix. One setup script and one skillset, owned by the platform team, define the toolchain and the rules for every agent session in the company, on any harness, using your existing model subscription.
The problems platform teams bring to an agent
A platform team serves every other team, so its backlog is made of other people's interruptions. The same four problems come up in almost every conversation.
The upgrade backlog never shrinks
Base images, language runtimes, Terraform providers, GitHub Actions versions, lockfiles in forty repositories. Each bump is small. Together they are a permanent queue that loses to every incident and every launch, until a security advisory makes one of them urgent.
A red pipeline interrupts someone every time
A flaky test, an expired token, a runner that ran out of disk. Someone stops what they are doing, reads the log, and finds a cause they have seen before. The fix takes ten minutes. The lost focus costs more.
Small infra changes wait on two people
A new environment variable, an IAM permission, a queue, a DNS record. Product engineers know what they need but not where it lives in the infrastructure repository, so they ask in #platform-help and wait.
Every engineer's agent is set up differently
Engineers already run Claude Code or Codex on their laptops, each with a personal config, personal credentials and no record of what ran. The platform team is asked to make this safe and consistent, and has no place to put the rules.
How Nori helps platform and DevOps teams
Requests from Slack become reviewed pull requests
A product engineer writes @nori add a PAYMENTS_WEBHOOK_SECRET variable to the staging and production services in #platform-help. Nori starts an isolated cloud machine with the infrastructure repository cloned. The agent finds the right module, makes the change, runs terraform fmt, terraform validate and terraform plan, opens a pull request with the plan output in the description, and replies in the thread. The platform team reviews a diff instead of writing one. Your pipeline applies it after approval; the agent does not.
Schedules run the chores
Cron automations start the same kind of session with nobody present. A weekly run upgrades dependencies and opens one pull request per repository. A nightly run reads the day's failed jobs and labels the flaky tests. Each run posts a summary to a channel and has a history entry with its transcript. See scheduled coding agents.
Webhooks turn failures into proposed fixes
Point a CI failure notification or an alert webhook at a Nori automation. The agent reads the failing job's log, reproduces the failure, and either pushes a fix as a pull request or posts what it found and who should look. The pattern is the same as turning a Sentry webhook into a reviewed fix PR.
Org-wide setup scripts and skillsets
The platform team owns one setup script that runs on every machine: clone these repositories, install these tool versions, log in to the internal package registry. It also owns the organization skillset: the AGENTS.md rules, the skills for your deploy and rollback process, and the subagents. Change either once and every later session, for every engineer and every automation, starts from it.
Scoped credentials and your own cloud
Integrations are scoped to the organization, a person or one custom agent, so the upgrade agent can be given read access to the registry and nothing in production. Enterprises deploy the full Nori stack, control plane included, into their own AWS VPC or Azure VNet, with their identity provider through SAML, SCIM or OIDC, their LLM gateway and their compute. What moves and what stays is explained in what an agent control plane is.
Any harness, your model account
Nori runs Jiro, its own engineering teammate, and also Claude Code, Codex, Gemini CLI and any ACP agent. Sessions use the Claude or ChatGPT subscription, API keys or LLM gateway you connect. Nori never charges for tokens, so the platform team can standardize the environment without choosing the model for everyone.
A worked example: the Monday dependency run
This is one automation a platform team can set up on the first day. The repository names, versions and counts are illustrative.
The schedule and the prompt
Schedule: 0 6 * * 1 (Mondays 06:00, team time zone)
Posts to: #platform-upgrades
Agent: platform-upgrader (custom agent, registry read-only)
Prompt:
For each repository in services/, do the following on a new branch
named deps/<yyyy-mm-dd>:
1. Update minor and patch versions in the lockfile. Do not take major
versions; list them instead.
2. Bump the base image in Dockerfile to the latest patch of the pinned
minor version.
3. Run the repository's test command from AGENTS.md.
4. If tests pass, open a pull request titled "deps: weekly upgrade".
If tests fail, bisect to the upgrade that broke them, leave it out,
and name it in the pull request description.
5. Post one summary table to the channel when all repositories are done.The summary in Slack
Nori 06:41 #platform-upgrades
Weekly upgrade, 4 repositories:
repo PR upgraded held back tests
billing-api #318 14 none pass
notifications #92 9 redis client 5 -> 6 pass
web-gateway #540 21 none pass
report-worker #77 6 pandas 2.2.3 (1 test) pass without it
Major versions available, not taken: redis client 6, eslint 10.
report-worker: tests/test_rollup.py::test_weekly_bucket fails with
pandas 2.2.3 (resample label change). Details in the PR description.The review
- The engineer on rotation opens the four pull requests. Three are green and small enough to approve after reading the lockfile diff.
- On the
report-workerPR she comments@nori fix the resample call so pandas 2.2.3 can be included. The agent pushes a follow-up commit to the same branch and replies with the test result. - She replies in the Slack thread:
@nori open a tracking issue for the redis client 6 upgrade and list the breaking changes that affect us. - The agent saves a shared memory:
report-worker pins resample labels; check test_weekly_bucket after any pandas bump. Next Monday's run starts with that note. - Merges go through the normal pipeline. The run and its transcript stay in the automation's history.
Automations to start with
| Automation | Trigger | Result |
|---|---|---|
| Weekly dependency upgrade | 0 6 * * 1 | One pull request per repository and a summary table |
| Flaky-test triage | 0 2 * * * | List of tests that failed then passed on retry, with a quarantine PR for repeat offenders |
| Pipeline failure on main | CI webhook | Root cause in the channel, plus a fix PR when the cause is in the repository |
| Terraform drift check | 0 5 * * 1-5 | terraform plan per workspace; non-empty plans posted with the diff |
| Expiring certificates and tokens | 0 8 * * 1 | List of items expiring within 30 days and the owner of each |
| Runbook freshness | 0 9 1 * * | PR that corrects commands and links in runbooks that no longer match the code |
Each of these is a prompt and a trigger. None needs a new service to maintain.
Guardrails a platform team should set
- Plan, do not apply. Give agents credentials that can run
terraform planand read state. Keep apply in your pipeline behind review. - Pull requests only. Protect main branches. Everything an agent proposes passes the same checks and reviewers as a human change.
- Separate agents for separate blast radii. Define a custom agent for infrastructure repositories with stricter instructions and narrower integrations than the general one.
- Write the rules down once. Put them in the organization skillset, so they hold for Slack requests, schedules and webhooks alike.
- Read the run history. Every automation run records what triggered it, what the agent did and what it produced. Review it the way you review pipeline logs.
To see this on your own repositories, book a demo.
Frequently asked questions
What can an AI agent do for a platform or DevOps team?
It handles repeatable, testable work: dependency and base image upgrades, CI failure diagnosis, flaky-test triage, small Terraform and configuration changes, drift checks and runbook updates. On Nori these start from Slack, a cron schedule or a webhook and end in a pull request your team reviews.
Can the agent make infrastructure changes safely?
Yes, when it proposes and your pipeline applies. Give the agent credentials that can read state and run a plan, keep apply behind review, and protect main branches. The agent opens a pull request with the plan output, and a person approves before anything changes.
How do we give every engineer the same agent setup?
The platform team owns one setup script and one organization skillset in Nori. The script clones repositories and installs tool versions on every machine. The skillset holds the instruction files, skills and subagents. Every session, for every person and automation, starts from both.
Can agents fix failing CI pipelines automatically?
Send your CI failure notification to a Nori webhook automation. The agent reads the failing job's log, reproduces the failure on its own machine, and opens a fix pull request when the cause is in the repository. Otherwise it posts the cause and the likely owner.
Can Nori run inside our own cloud account?
Yes. Enterprises deploy the full Nori stack, including the control plane, into their own AWS VPC or Azure VNet, or on-prem, with their identity provider through SAML, SCIM or OIDC, their LLM gateway and their compute. Hosted customers get a dedicated, single-tenant control plane per organization.
Do we have to standardize on one coding agent?
No. Nori runs Jiro, Claude Code, Codex, Gemini CLI and any ACP agent in the same sandboxes, with the same skillset and integrations. Teams can keep the harness they prefer while the platform team standardizes the environment, credentials and rules around it.