What is Bluebricks?

Learn what Bluebricks is, how the context layer enables safe agentic infrastructure, and how orchestration fits in

Bluebricks is an infrastructure platform that enables agents to discover, reason about, and operate your cloud infrastructure safely.

It starts by building a context layer: a structured map of every resource, relationship, and dependency across your cloud accounts and infrastructure code. This shared context is what makes autonomous infrastructure operations possible, because agents can see the full picture before they act.

Why this matters

AI tools for code are effective because code is self-contained. Infrastructure is not.

Infrastructure is fragmented across systems. Terraform manages declared resources, cloud providers reflect runtime state, and Git repositories store the source of truth. Each system operates independently, with no shared understanding of how they connect.

Without that connection:

An agent that only sees your code cannot determine what is actually running
An agent that only sees your cloud cannot determine what is managed or intended
Changes are difficult to reason about, validate, and execute safely

Giving an agent access to your cloud account is not enough. It needs a structured, continuously updated model of how your infrastructure fits together. That is the context layer.

The context layer

When you connect your cloud accounts and infrastructure code, Bluebricks builds a context layer: a structured map of your entire infrastructure environment. The context layer captures:

Every cloud resource across connected AWS, Azure, and GCP accounts, whether managed by code or not
Live Kubernetes state on managed clusters (EKS, GKE, AKS) discovered through those cloud connections; see Kubernetes Integration
Relationships between resources: networking dependencies, IAM bindings, service connections, cross-account references
Code-to-cloud mapping: which resources are governed by infrastructure code, which modules manage them, and where the code lives
Drift detection: differences between what your code declares and what is actually running

The context layer updates continuously. When you connect a new cloud account, Bluebricks runs discovery: a read-only scan that indexes every resource in that provider. Discovery refreshes periodically so the context layer reflects the current state of your infrastructure, not a stale snapshot.

This is the foundation that the rest of Bluebricks is built on. The agent queries the context layer to answer questions, identify risks, and execute changes. The orchestration platform uses it to resolve dependencies and generate accurate plans.

How agents operate safely

The context layer does not just give agents visibility. It constrains how they operate.

Because the agent sees the full dependency graph before acting, it can predict the impact of a change before proposing it. Every change the agent makes follows the same governed workflow as manual operations:

Plan before apply: the agent generates a plan showing exactly what will change. Nothing executes until you approve
All changes go through IaC: the agent does not make direct cloud API calls. Changes are codified in pull requests or environment runs, version-controlled, and auditable
RBAC and policies are enforced: the agent respects your collection-level roles, permissions, and policies. If you cannot approve a deployment manually, the agent cannot do it for you
Organization-scoped: all queries and actions are scoped to your organization at the database level. The agent cannot access resources outside your org

This is not a set of guardrails bolted onto a chat interface. The context layer and governance model are the same system, so safety is structural, not behavioral.

For a detailed look at how the agent uses the context layer to discover, remediate, and deploy, see Agent Overview.

Orchestration

Alongside the agent, Bluebricks provides a full orchestration platform for governed, repeatable deployments. You define reusable building blocks, target them at specific cloud accounts, and run deployment pipelines with plan/approve/apply cycles.

The agent and the orchestration platform share the same context layer, governance rules, and approval workflows. Teams can use either interface, or both, depending on what fits their workflow.

Bluebricks organizes orchestration around three core concepts: packages define what you deploy, collections define where it goes, and environments define how it runs.

Packages

A package is a reusable unit of Infrastructure as Code (IaC). Instead of managing raw Terraform modules, Helm charts, or CloudFormation templates directly, you wrap them into packages that expose clear inputs, outputs, and metadata.

More about packages

There are two types of packages:

Artifact: a single IaC component (a Terraform module, a Helm chart, a Bicep template) with defined inputs, outputs, and metadata. Artifacts are building blocks you compose into blueprints
Blueprint: a deployable template made of one or more packages. A blueprint wires artifacts together, sets defaults and constants, and exposes only the inputs the deployer needs to provide

For example, you might have a VPC artifact and a subnet artifact. A network blueprint composes the two, passes the VPC ID into the subnet, and exposes only region and cidr_block as inputs. The deployer never touches the underlying wiring.

Blueprints support Terraform/OpenTofu, Helm, CloudFormation, Bicep, and Generic artifact types, so you can mix IaC tools within a single blueprint.

Collections

A collection is the deployment target. It groups a cloud account, access rules, shared configuration, and governance policies into one place.

More about collections

Every collection can include:

Cloud account: the AWS account, GCP project, Azure subscription, or on-premises target where resources are created
Properties and secrets: collection-scoped values (like region, project_id, or database credentials) that are automatically inherited by every package deployed to the collection. This keeps packages reusable while adapting them to each target
RBAC: member and owner roles that control who can create, approve, or execute environments in the collection
Policies: guardrails like Owner Approval, Cost Limits, and Allowed Blueprints that govern what runs and under which conditions

Collections map to how your organization already works. For example, dev-us-east-1, staging, and prod-eu-west-1.

Environments

An environment is the workflow that deploys a package into a collection. It is where what (the package) meets where (the collection) and produces real infrastructure.

More about environments

When you deploy an environment, Bluebricks evaluates the package and all its dependencies to produce a unified plan of changes. You can preview the plan, approve it, and apply or destroy the resources when they are no longer needed.

Each execution creates a run. A run captures the plan, logs, state updates, and outputs in a single auditable record. Runs are fully versioned, so you can trace exactly how your infrastructure evolved and why.