Knowing what is running is not the same as knowing why
Most tools tell you what is running. The Lens holds why it is built the way it is, the decisions made at onboarding, the intent behind them and what to prioritise or ignore. It then checks every change against that, so nothing quietly drifts.
Agents analyse your AWS environment continuously and findings arrive where your engineers already work. Pull requests in GitHub, messages in Slack, checks in your CLI, context inside your IDE. Not a dashboard you have to visit.
The agents read the same operational signals base2's toolkit produces, monitoring, cost, security posture and compliance, and weigh every change against your intent, so drift surfaces as a pull request before it becomes an incident.
Your team reviews. Your team executes. We provide the analysis, the context and the intent behind it.
Ask Infrastructure Lens from your AI tools
Infrastructure Lens captures the context behind your AWS environment: what runs, why it exists, how it is built, what depends on it and how it recovers. Ask about AWS exposes that context through MCP, so your team can ask questions from Cursor, Claude Desktop or another MCP client without digging through consoles, tickets, code repositories and runbooks.
What it answers from
- AWS state across your accounts
- Infrastructure code and architecture designs
- Captured decisions and intent
How it stays controlled
- Read-only against AWS accounts
- Signed-in users, not shared standing keys
- Answers from your operating context
Where action goes
- Support history, recovery paths and playbooks included
- Approved changes through pull requests, pipelines, CloudFormation or base2 tools
- No bypass around your review path
Under the hood
Specialist agents that never stop working. They run read-only against your AWS accounts and surface what matters, every change measured against the decisions and intent captured at onboarding. No changes made to your environment without your team reviewing first.
It publishes pull requests, you ask questions
One engine, two directions. Findings reach your team as pull requests to review, and your team asks the same engine what anything is for, how it recovers and what just changed.
Findings through your approved paths
Findings arrive as pull requests your team reviews and merges, Slack threads your engineers reply to, checks in your CLI and context in your IDE. Where action is needed, recommendations route through the path your team already trusts: pull requests, pipelines, CloudFormation, base2 tools or your internal tools.
- Pull requests in GitHub, reviewed and merged by your team
- Slack threads with interactive approvals
- CLI checks before deployment
- Context inside your IDE
- CloudFormation, base2 tools or your own tooling where that is the approved control path
Answers over MCP
Connect Cursor, Claude Desktop or Claude Code over the read-only MCP and ask. Is this alert real, what is this for, how does this recover, what just changed. Answered from your intent, support history and playbooks.
- What backups failed last night, answered from live operations
- Why a resource is built the way it is, answered from your decisions
- How a service recovers, answered from your playbooks
- Signed in as you over OAuth, read-only against your AWS accounts
What you get
Pull Requests
Findings arrive as reviewed PRs in your GitHub repo. Specific changes, specific context. Review and merge.
Slack Integration
Two-way and real-time. Findings post into your channels, your team replies in thread to dig deeper and approves any action before it is routed through the right control path.
CLI Checks
Run the same agents against a branch, a stack or a new service before it reaches production. On-demand intelligence at deploy time.
IDE Context
Infrastructure context inside Claude Code via MCP. Your AI coding tools understand your environment, not just your code.
Pattern Analysis
What is running, why it was built that way and what should not be repeated. The operational knowledge your codebase cannot tell you.
Compliance Mapping
Findings mapped to SOC 2, ISO 27001 and PCI. Not generic alerts. Framework-specific context your team can act on.
Architecture Drift
Every infrastructure change cross-referenced against the architectural decisions made at onboarding. When AI tools or engineers drift from the target, you see it before deployment.
What is included
The Analysis
- Continuous AWS environment scanning
- IAM configuration and access analysis
- Architecture drift against your decision registry
- Architecture pattern identification
- Cost anomaly detection and rightsizing
- Infrastructure documentation from live resources
The Delivery
- Findings as GitHub pull requests
- Slack integration for your engineering channels
- Interactive Slack approvals before action routes to tools or workflows
- CLI checks before deployment
- Recommendations routed through CloudFormation, base2 tools or your internal tools where appropriate
- IDE context via the Infrastructure Lens MCP
- Questions answered over MCP in Cursor, Claude Desktop and Claude Code
- Prioritised findings with remediation guidance
The Context
- Compliance framework mapping (SOC 2, ISO 27001, PCI)
- Operational knowledge encoded into findings
- What to ignore and what to prioritise
- Architecture guidance and advisory
- Roadmap reviews to ensure everything is on track
How it works
Your environment is analysed continuously. Findings arrive where your engineers work. Your team decides what to act on.
Scan
Agents read your AWS environment. What is running, how it is configured, what has changed.
Analyse
Findings prioritised by impact. Mapped to compliance frameworks. Context provided for each.
Deliver
Pull requests, Slack, CLI, IDE. Findings arrive where your engineers already work.
Advise
Our team explains the why. What to fix first, what to monitor, what patterns to break.
What our customers say
We have leaned very heavily on their expertise, both during the initial design and conception of these new systems as well as while we rolled them out into production.
They shared their knowledge and upskilled our own team and that of our other partners.
Read case study
Audited and certified
ISO 27001
AWS DevOps Competency
AWS SaaS Competency
See what the Lens finds in your environment
Walk us through your AWS setup. We will show you what the first analysis covers.
Case Studies
Real results from companies we work with
