Give every agent the same live context
A continuously refreshed map of your cloud, code, and chat, served over MCP to every AI agent you run. No per-agent wiring, no rules files to keep alive.
Grounded coding and review
Example 1 · Writing the change
The scenario
An engineer opens Codex to change the checkout service.
Behind the scenes
Before writing anything, Codex calls B.O.R.I.S over MCP: what is deployed, which versions are running, and how the services connect - instead of inferring it all from the repository.
The outcome
B.O.R.I.S surfaces what the repo doesn't show: another service reads checkout's data, so Codex's plan covers both - and the code targets what is really deployed.
Why it matters
Fewer pull requests that looked right to the AI and broke on contact with production.
Engineer
Add a per-customer rate limit to the checkout service - plan it before you touch any code.
Codex → B.O.R.I.S MCP
What's deployed for the checkout service, what's it running on, and what reads its data?
B.O.R.I.S.
The checkout-app runs on the services EKS cluster in the production AWS environment - two healthy replicas across two Availability Zones, fronted by the checkout-app gateway.
The cache is Valkey 8.0.1, not Redis. The reporting-worker reads the same orders table, so a rate limit on the write path affects it too. Application code and Terraform config live in the checkout-app repository.
Codex → Engineer
Plan: rate-limit at the gateway, not in the app - and reporting-worker reads the same table, so I'll cover its path as well. Writing against Valkey 8.0.1, not Redis.
The same context reaches Cursor, Claude Code and the review agent in CI. It isn't wired per agent.
Example 2 · Reviewing the change
The scenario
A pull request raises the checkout database pool size. The review agent in the GitHub Action checks it against production, not just against the diff.
Behind the scenes
The action runs an AI reviewer that reads live context from B.O.R.I.S: the current connection limit, what else shares that instance, and the team's past incidents on it.
The outcome
The review flags that the change exceeds a production limit and cites the incident the team already had - before merge, not after the page.
Why it matters
Code review that knows your infrastructure, not just your code.
Pull request
checkout-service/config.yaml - max_pool_size: 100 → 200
Review agent in GitHub Actions → B.O.R.I.S MCP
What's the production connection limit for the checkout-service database, what else uses that instance, and are there past incidents on it?
B.O.R.I.S.
Production runs the shared database at a 160-connection limit, and the worker service uses the same instance. Team memory records a connection-exhaustion incident on this pair.
Review agent in GitHub Actions → Pull request
Requesting changes: 200 exceeds the shared instance's 160-connection limit and worker-service is on it too. Cap at 100, or resize in Terraform first - linking the earlier connection-exhaustion incident.
The reviewer in CI reads exactly what the engineer's agent read. Same context, no second setup.
Production support, where it gets reported
Example 1 · A partner escalation in Slack
The scenario
A partner calls: their prescriptions aren't reaching the pharmacy. Someone asks Claude tag to look into it, right in the Slack thread.
Behind the scenes
Claude tag calls B.O.R.I.S over MCP - stored context for how the pipeline fits together, plus read-only live lookups for current service status and recent deploys. No extra MCP servers wired into Slack, no production credentials handed to the bot.
The outcome
The cause is a deploy from earlier that day. Claude tag posts the evidence in-thread and opens the rollback PR for the team's review.
Why it matters
Partner escalations get answered in minutes with evidence, in the channel where they were reported - not after a day of log archaeology.
Support engineer in Slack
@Claude a partner says their scripts aren't reaching the pharmacy - can you check why?
Claude tag → B.O.R.I.S MCP
What's the live status of the pharmacy integration service, and what changed recently?
B.O.R.I.S.
The pharmacy integration service has rejected every partner message since 14:05 - schema-validation errors. The errors began right after deploy 2049, which changed the outbound message format. The prior deploy, 2048, was the last version accepting messages.
Claude tag → Support engineer in Slack
Rejections started at 14:05, immediately after deploy 2049 changed the outbound format. 2048 was the last good version - rollback PR opened with the log evidence attached.
What Claude tag learns in this thread is available to the engineer's coding agent an hour later, and to the reviewer on the fix PR.
Example 2 · Enriching the AI SRE you already run
The scenario
Your on-call automation already triages alerts - an AWS DevOps agent, an AI SRE, or your own responder loop. It just doesn't know your systems.
Behind the scenes
The responder adds one MCP server. Ownership, dependencies, recent changes and past incidents come from B.O.R.I.S; the agent keeps its own runbooks and actions.
The outcome
Instead of "the checkout latency alarm is firing", the page arrives with the dependency chain, the change that landed twenty minutes earlier, and the team that owns the service.
Why it matters
You don't replace the tooling you already run - you stop it working blind.
Alert
ALARM: checkout-api p99 latency above 2s for 10 minutes
AI SRE agent → B.O.R.I.S MCP
What does checkout-api depend on, what changed in the last hour, and have we seen this alarm before?
B.O.R.I.S.
checkout-api reads the shared Valkey cache and the orders database. The cache was resized 25 minutes ago by change 4187 in the platform-infra repository.
Team memory holds one prior p99 alarm on this service, traced to cache eviction after a resize - with the runbook the team used then.
AI SRE agent → Alert
Paging platform-infra, not checkout: cache resize 4187 landed 25 minutes before the alarm and matches a prior eviction incident. Runbook attached.
One connection, and every other agent in the company is reading the same picture of the incident.
Security questions answered across code and cloud
Example 1 · CVE exposure, in one pass
The scenario
A CVE lands in a library your team depends on. Are we exposed, and where?
Behind the scenes
The scheduled security job runs Claude Code, which asks B.O.R.I.S which services depend on the library, what each one pins, where each runs, and which are reachable from outside - code and cloud in one pass.
The outcome
A prioritized exposure list in minutes: which services are affected, which one is public-facing, and the patch order - with the repos and version pins to change.
Why it matters
CVE response stops being a grep-and-guess across twenty repositories.
Advisory feed
New advisory: CVE-2026-4471 in jackson-databind. Assess exposure.
Claude Code in CI → B.O.R.I.S MCP
Which services use jackson-databind, what versions, and which are reachable from outside?
B.O.R.I.S.
Three services are affected. payments-api is public-facing behind the ALB; billing-worker and audit-consumer are internal-only. Version pins live in payments-api and billing-worker.
Claude Code in CI → Advisory feed
Patch payments-api first - it's the only internet-facing one. Report filed with repos, pinned versions and exposure paths for all three.
No security-only copy of the inventory: this is the same context your engineers' agents use every day, so it can't drift apart from theirs.
Example 2 · Context for your AWS security agent
The scenario
Your AWS security agent reports a misconfiguration. Whether it matters depends on what AWS can't see: who owns the resource, what depends on it, and whether anything reaches it.
Behind the scenes
B.O.R.I.S answers the questions the finding leaves open - ownership, dependencies, the actual network path, and the repository where the configuration is defined.
The outcome
The finding arrives with an owner, a blast radius, and the Terraform file to change - so it gets triaged instead of queued.
Why it matters
Findings become work items instead of a backlog nobody can prioritize.
Finding
Security group sg-0f21c allows 0.0.0.0/0 on port 5432.
AWS security agent → B.O.R.I.S MCP
What uses sg-0f21c, is anything on it reachable from the internet, and which repository defines it?
B.O.R.I.S.
sg-0f21c is attached to the analytics database in the data account. It sits in a private subnet with no route to an internet gateway, so the rule isn't currently reachable from outside.
The rule is defined in the data-platform repository, terraform/analytics/network.tf. The data team owns that path.
AWS security agent → Finding
Downgrading to medium: no internet path today, but the rule is a latent one. Assigned to the data team with the exact Terraform file to narrow.
The engineer who picks up the finding gets the same context in their coding agent - nothing has to be re-explained on handover.
Onboarding and knowledge continuity
Example 1 · A new engineer's first week
The scenario
A new engineer's first week. Instead of interrupting the two seniors who know everything, they ask B.O.R.I.S in Slack.
Behind the scenes
The Slack Assistant answers from the team's accumulated context - architecture, conventions, decisions, and the current state of every environment.
The outcome
Real questions answered in seconds from day one, with pointers to the right repos and services to explore next.
Why it matters
Onboarding stops costing a senior engineer's week - and new joiners inherit the full team context instead of assembling it from tribal osmosis.
New engineer in Slack
@B.O.R.I.S I'm new here - how does a change get from a PR to production?
B.O.R.I.S.
Welcome! Merges to main build in GitHub Actions and deploy to staging automatically. Production is tagged releases, applied per runtime - the ECS services through Terraform, the EKS workloads through the deployment repository.
Start with the vote-app repository; ask me about any service and I'll show you what it talks to and who's been working on it.
The same context their coding agent will read on day two. They learn the system once, not once per tool.
Example 2 · "Why is it built this way?"
The scenario
The question lands a year after the engineer who made the decision left the company - and it lands in Cursor, mid-change.
Behind the scenes
Decisions, gotchas and conventions are captured into team memory as work happens. Any agent retrieves them - here, Cursor.
The outcome
The original rationale surfaces instantly, with its trade-offs - so the change is made knowingly instead of by archaeology or gamble.
Why it matters
The context behind your systems outlives the people who created it.
Engineer in Cursor
Why does the vote service run on Spot capacity only? Safe to add on-demand?
Cursor → B.O.R.I.S MCP
Is there a recorded decision on why the vote service runs Spot-only? Any known trade-offs?
B.O.R.I.S.
Team memory holds a decision captured during an investigation: vote runs FARGATE_SPOT-only to cut cost, with a known trade-off of intermittent 503s when Spot capacity dips. Recorded by an engineer who has since left the company.
Cursor → Engineer in Cursor
There's a deliberate decision behind it - Spot-only for cost, accepting occasional 503s. Adding on-demand capacity is safe technically, it just reverses that cost trade-off. Worth confirming with the service owner.
Captured in whichever agent hit it first, retrieved by whichever agent needs it next.
Time and token savings
Example 1 · No crawl, no rules files to maintain
The scenario
How much of your AI spend goes to re-explaining your own systems, session after session?
Behind the scenes
Without context, an agent burns its session rediscovering your stack - or trusts a rules file that went stale last quarter. With B.O.R.I.S it grounds itself in a handful of reads from pre-computed, continuously refreshed context.
The outcome
Same agent, same task: a few grounded reads instead of a long exploratory crawl - and the answer reflects today's system, not last quarter's Markdown.
Why it matters
Keep skills and rules files for what's durable: conventions, business rules, how your team works. Infrastructure changes every week, and a static Markdown file is the wrong medium for it - B.O.R.I.S tracks the change in the background, so nobody spends Fridays updating context by hand.
Engineer
Where is this service deployed, and what cache does it use? I want to make a change.
Codex → B.O.R.I.S MCP
Where is this service deployed, what's it running on, and what cache does it use?
B.O.R.I.S.
The service runs on the services EKS cluster in the production AWS environment. The cache is Valkey 8.0.1, not Redis. Application code and Terraform config live in the service's repository.
Retrieved read-only from AWS and GitHub.
One context layer to keep current - not one rules file per repository, per agent, per team.
Example 2 · Two teams, two agents, one context
The scenario
The platform team standardized on Codex. The product team prefers Cursor. Neither wants to maintain its own account of how the stack works.
Behind the scenes
Both connect to the same B.O.R.I.S over MCP. A decision captured in a Codex session is there for the next Cursor session - and for Claude tag in Slack, and for the review agent in CI.
The outcome
The answer comes back in seconds in whichever agent asked, with no context stranded in the tool that originally discovered it.
Why it matters
Agent choice stops being a context decision. Teams pick the tools they like; the company keeps one memory.
Engineer in Cursor
Why is the orders consumer capped at four replicas? Can I raise it?
Cursor → B.O.R.I.S MCP
Any recorded decision on the orders consumer replica cap?
B.O.R.I.S.
Yes - captured last month from a platform-team session in Codex: the cap is four because the downstream partner API throttles above 40 requests per second. Raising it needs a quota increase from the partner first.
Retrieved read-only. The same context is served to Cursor, Codex, Claude tag in Slack, and review agents in CI.
Cursor → Engineer in Cursor
Don't raise it yet - the cap exists because the partner API throttles above 40 rps. The quota increase has to come first.
Recorded once by whoever hit it first, in whatever agent they were using - available to everyone else's agent from then on.