Autonomous mapping, minus the slop: how Dreeze builds Application Maps

You’ve probably been there before: asked to draw an architecture diagram or dependency map, or worse, to make sense of one drawn by someone who left the company two years ago and only got as far as, “It has some EC2, RDS, and a VPC. Maybe S3.” 

Every cloud application has a dependency nobody put on the diagram. Usually it’s something small, like the key that encrypts a volume, the role a serverless function runs as, the managed identity an Azure app signs in with. It stays out of sight right up until a recovery, when the data comes back, the application still won’t start, and the app owner is beating down your door.

Dreeze closes that gap with an agentic system of AI agents and deterministic workflows. Together, they safely read your cloud accounts, work out what every resource depends on, and propose the applications those resources add up to. It’s a three-actor model: AI agents handle the judgment calls. Deterministic workflows decide every dependency. Your team reviews and tunes the result. 

The finished output, the Application Map, is saved with every backup, so recovery rebuilds each application the way it was at the point in time you choose.

Here’s how it works, and why we built it so you don’t have to build maps manually and no AI agent ever gets to make haphazard guesses at what your application needs.

Restoring the data ≠ recovering applications

A cloud-native application is often spread across hundreds, even thousands, of resources: functions and containers, databases and buckets, networks, identities, keys, and secrets. Backup tools are good at the data. Everything else lives in configuration, and configuration is what your team ends up cobbling together from memory when something breaks.

The usual sources of truth don’t help much at that point. Architecture diagrams describe the system someone designed. Runbooks describe the system as it was the last time someone updated them. Tags and IaC record intent, and the live environment has usually drifted from both.

There’s a mismatch in the tooling, too. Most dependency mapping comes from observability, where the question is which service talks to which. Recovery asks something else: what has to exist, and in what order, before this application can run? A traffic map can show that your API calls your database. It won’t tell you that the database needs its subnet group and its encryption key before it can come back at all.

What Dreeze counts as an application

In Dreeze, an application usually starts with the compute that does the work: functions, container services, Kubernetes workloads, and VMs/instances. Sometimes it starts with a database that stands on its own. From there, it includes every resource those starting points depend on, followed all the way down the cloud-native rabbit hole. The function needs its role. The database needs its network. The volume needs its key.

Real environments overlap, so the model allows for it. A shared database or VPC can belong to several applications at once, and you decide what to protect.

How Dreeze’s agentic discovery builds the Application Map

Building the map is an agentic system with a clear division of labor. Deterministic workflows run the pipeline, and AI agents work inside it as governed components, each with one job and a hard boundary around it. It’s the same line Anthropic draws between workflows and agents, and the one enterprise AI teams keep landing on: let models interpret, let code decide. I’ll explain why that matters so much for recovery further on.

Inventory workflows read every account, region, and cluster

Inventory workflows enumerate every supported resource across your AWS accounts and Azure subscriptions, either once a day or whenever you ask. They read configuration through read-only access and store it exactly as the cloud reports it. Nothing gets interpreted at this stage. For Kubernetes, they connect to each cluster directly and inventory what runs inside it, namespace by namespace, Helm releases included. Dreeze recognizes more than 150 resource types today.

Mapping workflows work out what each resource depends on

Mapping workflows turn that raw configuration into dependencies. Each resource type has its own purpose-built rules, which our engineers wrote after more than a few hard-won lessons in the cloud-native trenches, plus deep research into how these applications really fit together beyond what AWS and Azure document. The docs might say that a function has a role attached. The rules know what that means in practice: the role has to be back in place before the function can run. 

Put it all together and you get typed, directional dependencies like these:

• A Lambda function runs as an IAM role and reads a secret named in its environment variables.
• An RDS database sits in a subnet group, which places it in specific subnets inside a VPC.
• An EBS volume is encrypted with a KMS key.
• A Kubernetes deployment mounts its config maps and secrets and runs under a service account tied to a cloud IAM role.
• An Azure Function App depends on its storage account, and an App Service app runs on its App Service plan.

Each dependency is marked as either required for recovery or optional. A required dependency means the resource can’t come back without it. An optional one, like a logging setting, is nice to have. That distinction matters later because it decides whether a recovery plan is ready to run. 

These rules are grounded entirely in your configuration. The same configuration produces the same map every time.

The discovery agent proposes your applications

With the dependencies mapped, the Dreeze discovery AI agent works out where applications begin. It starts with what your teams have already declared:

• Application tags on your resources
• Kubernetes namespaces, and the Helm charts deployed in them
• Azure resource groups
• Terraform code, read from the GitHub repositories you connect

All of these help, and none is required. Declared sources carry the most weight, and they win any conflict.

Most estates also have large stretches nobody labeled. So the discovery agent reads resource names, tags, and the dependency graph, then reasons about which pieces of compute belong together and what the group should be called. Each proposal comes back in a fixed, structured format with a confidence score and a reason. Before anything is saved, deterministic checks go over every proposal. They merge duplicates, hold declared applications exactly as declared, discard weak or generic guesses, and strip out anything that should never be part of an application.

Once the starting resources are set, the agent stops proposing and the rules take over. App membership is calculated by following dependencies outward from them. The rules also know which direction not to follow. For example, if your application depends on a shared VPC, every other tenant of that VPC doesn’t get pulled into your application along with it.

Probabilistic where judgment helps, deterministic where proof matters

Dependency mapping involves two kinds of work, and they call for different tools. Some of it is judgment. Is this bucket holding customer records or build artifacts? Is this cluster production or staging? Which of these hundreds of unlabeled functions belong to the same service? Rules and traditional algorithms handle those questions badly. A well-guarded AI model handles them well.

Some of it is fact. Does this function run as this role? Does this database live in that subnet? What has to exist before what? A model has no business guessing at those, because a wrong guess stays hidden until the worst possible moment. And the odds compound. An application can depend on hundreds of resources, so a model that’s right 95% of the time on each one would still get the whole map wrong more often than not.

So Dreeze splits the work:

The guardrails are simple to state. Every AI agent runs as a governed component: it answers in a structured format from a fixed vocabulary Dreeze defines, and it can’t add a dependency. It can propose where an application starts, but deterministic workflows decide everything that belongs to it from there. Deterministic checks validate what they produce, and anything your teams declared or corrected outranks them. If a model call fails, the dependency map is still complete. Every application records how it was created, so you can always tell an AI proposal from a tag, a namespace, or a decision your team made.

This is how Dreeze avoids recovery slop. A hallucinated application is something your team can spot and fix in a review. A hallucinated dependency would probably only surface in the middle of a recovery, which is exactly why no model gets to create one. The same backup produces the same recovery plan every time, and that plan holds up when your boss, or your auditor, pops in to ask how it was built.

Mapping with humans in the loop

AI agents write the first draft, deterministic workflows check it, and you have the final word since every map is tunable:

• Add a resource the agents missed, or exclude one that doesn’t belong.
• Draw a dependency the configuration doesn’t show, such as one service calling another through a hard-coded URL. Dependencies you add count as required and shape the recovery order.
• Filter applications by how they were created, and exclude a whole category at once.
• Bring in something Dreeze can’t see, like an on-premises service or a third-party API, and give it a webhook so it takes its place in the recovery order.
• And if you’re really feeling ambitious: create an application from scratch by choosing the resources yourself.

Your corrections persist across every rescan so that an AI agent doesn’t unexpectedly decide to redraw the Application Map after you’ve fine-tuned it.

From map to recovery

The map matters most on the day you need it. Dreeze saves each resource’s dependencies alongside its backup in the vault, immutably locked for as long as the recovery point is kept. When you recover, Dreeze doesn’t consult today’s map, which may have drifted. It rebuilds from the map as it stood at the recovery point you chose.

Revival automation turns that map into a recovery plan. Order comes from the dependencies themselves rather than a fixed sequence of phases. Each resource starts the moment everything it needs is ready, so independent branches run in parallel. If a required dependency is missing from the vault, the plan flags it before anything runs. As each resource comes back, its new identifiers flow to the resources that depend on it, so references point at the recovered copies and not the originals. Afterward, you get everything you need to pick the environment back up with your own Terraform.

You can also run that same plan as a test. Recover into an isolated account whenever you want or on a schedule, and Dreeze cleans up afterward. The plan you test is the plan you’ll run for real.

What it looks like in the platform

Open any application in Dreeze and the Application Map lays out its resources in layers, from ingress through compute, data, messaging, and identity. Expand it and you’ll usually land on the dependency nobody drew: a key, a secret, a role, a queue. A second view shows where applications overlap, so you can see which shared resources several applications rely on before you plan a recovery.

What it looks like for your applications

Application Revival starts with knowing what each application needs, and the best test of any dependency map is an application you already know well. Reach out to us for a free, read-only assessment of an app or two if you want to see exactly what autonomous mapping picks up in your cloud estate.