Map What Your AI Agent Depends On Before Something Breaks

An AI agent dependencies map is a one-page list of everything the agent needs in order to work: the models it calls, the accounts and credentials it uses, the APIs and tools it reaches, the documents it reads and the people who approve or maintain it. For each item you record an owner, what failure looks like and whether a fallback exists. Any item with no fallback and no second person who understands it is a single point of failure, and those are the ones to fix first.

Key takeaways

• List dependencies in five groups: models, accounts and credentials, APIs and tools, documents and data, and people.
• For every entry, write down an owner, what breaks without it, how you would notice, and what the fallback is.
• A single point of failure is anything with one owner, one copy, one login or one supplier and no tested way around it.
• Personal accounts and undocumented human knowledge are the most common hidden dependencies.
• Review the map on a schedule and whenever the agent's role, tools or permissions change.

Why map dependencies before something breaks?

An agent that works well in week one feels self-contained. It answers questions, drafts replies or updates records, and nobody asks what is underneath. In practice the agent is a chain: a model produces the reasoning, an account lets it into a system, an API returns data, a document tells it the current policy, and a person decides when its output is good enough to act on. If any link changes, the agent does not usually crash with a clear message. It gets quietly worse, or it stops, and the first person to notice is often a customer.

Most incidents with business agents are not dramatic model failures. They are ordinary events: an employee leaves and their login is disabled, a vendor changes an interface, a shared folder is reorganized, a token expires over a weekend. A map turns these from surprises into known risks with a known response.

The map is also a decision tool. When someone proposes a new tool connection or a new data source, you can see what it adds to the chain. If you already keep a one-page architecture map, the dependency map is its companion: the architecture map shows the parts, and the dependency map shows which parts you cannot lose.

What belongs on the map?

Start with what the agent touches, not with what the vendor says it uses. Walk through one real task from request to finished work and write down every thing it needed along the way. Then group the entries.

Models. Name every model the agent calls, including any used for smaller steps such as classification, summarizing or checking. Note who hosts each one, which version or alias you rely on, and whether the provider can retire or change it. If you only ever call one model, say so plainly. That is a fact worth seeing on paper.

Accounts and credentials. List every login, API key, service account and token the agent holds. Record whose name the account is under, where the secret is stored, when it expires, and what it is allowed to do. The Google OAuth 2.0 documentation is a good reference for how delegated access and token expiry work, and the OWASP Authorization Cheat Sheet is a useful reference when deciding what each account should be allowed to do.

APIs and tools. List each system the agent reads from or writes to: the CRM, the ticketing tool, the calendar, the email service, the internal database. If tools are exposed through a standard such as the Model Context Protocol, list each connected server as its own entry. Note who maintains the connection and what happens if the other side changes.

Documents and data. List the policies, price rules, product sheets, templates, knowledge bases and example files the agent consults. For each, record where the master copy lives, who is allowed to edit it, and how the agent finds the current version. Anthropic's writing on context engineering for agents explains why what the agent can see at the moment of a task shapes its behavior, which is exactly why stale or missing documents matter.

People. List who approves risky actions, who answers when the agent escalates, who maintains the connections and who decides about changes. Include the person who knows why the agent was set up the way it was. This group is the one most often left off the map, and it is the one that fails most quietly.

What should you record for each dependency?

A map is only useful if every row answers the same questions. Keep the fields few so that people actually fill them in.

• What it is, in plain words (for example, the shared mailbox the agent sends from).
• What the agent uses it for, in one sentence.
• The owner, as a named role and a named backup.
• Where access is controlled and how it is renewed.
• What failure looks like from the outside: errors, silence, wrong answers or slow responses.
• How you would notice, and how quickly.
• The fallback, if any, and when it was last tested.
• The date the entry was last checked.

The last two fields do the most work. A fallback that exists on paper but has never been exercised should be recorded as untested, not as covered.

How do you recognize a single point of failure?

A single point of failure is not always a big or expensive component. It is any dependency where one event removes the agent's ability to do its job and you have no prepared way around it. Ask these questions of every row.

• If this disappeared today, would the agent stop or produce wrong output?
• Is there only one person who knows how it works or how to renew it?
• Is it tied to a personal account, a personal device or a personal email address?
• Is there only one copy, and is that copy backed up somewhere you have actually restored from?
• Is there only one supplier, with no alternative you could switch to within a reasonable time?
• Does the agent depend on a version, alias or setting that the supplier can change without asking you?
• Would you find out from your own monitoring, or from a customer?

A row that gets a yes on any of the first five is a candidate. A row that gets a yes on two or more goes to the top of the list. The last two questions rate how bad the failure will be once it happens, so use them to order the candidates.

Be careful with dependencies that look redundant but are not. Two models from the same provider share the same account and the same outage. Two approvers who both sit in the same team share the same holiday calendar. Two copies of a document in the same drive share the same permissions. Redundancy counts only when the failure of one does not take down the other.

How do you build the map in one working session?

You do not need a special tool. A shared document or spreadsheet with the fields above is enough. The aim is a first honest version within a few hours, not a perfect one.

• Pick one agent and one real task. Choose the task that matters most, such as answering a customer, preparing a quote or reconciling a record.
• Trace the task end to end. Ask the person who owns the process to walk through it while someone writes down every system, file, login and person involved.
• Check each entry against reality. Open the settings. Look at which account a connection runs under, rather than trusting memory.
• Fill in the fields for each row. Where you do not know an answer, write unknown. Unknowns are findings.
• Mark single points of failure using the questions above, and sort them by how quickly you would notice and how much damage a failure would do.
• Assign an owner and a first action to each marked row. Keep actions small: add a backup owner, move a secret to a shared vault, write down the renewal steps.
• Set a review date and attach the map to the agent's change process, so that new connections or permission changes update it.

Tie the map to your permission review. The two exercises overlap: the permission review asks whether each access is justified, and the dependency map asks whether each access is survivable.

What does this look like in practice? (An illustrative scenario)

This scenario is illustrative, not a real engagement. Imagine a distribution company with an agent that answers customers about order status and returns. It reads order data from the company's order system, replies from a shared support mailbox, and follows a returns policy kept in a document.

The team traces one task: a customer asks whether a return is accepted. The map shows the following.

• The connection to the order system runs under the login of an operations manager who is the only person who has ever renewed it.
• The returns policy exists as a document on one coordinator's personal drive, and the agent reads a copy that was pasted in months ago.
• The agent calls a single model through a single provider account, with no tested alternative.
• Escalations go to one team lead, with no named backup.
• The shared mailbox is fine: it has two admins and a documented recovery process.

Four rows are single points of failure, and none of them is a technical surprise. The fixes are modest: create a dedicated service account for the order system with a documented renewal step, move the policy to a shared location with a named owner and a clear process for updating what the agent reads, name a backup for escalations, and decide in advance what the agent does if the model is unavailable (for example, stop and hand over to a person with a short holding message). The mailbox row is left alone. The value of the map was in separating what needed action from what did not.

What should you do about each single point of failure?

Not every single point of failure deserves the same response. Use this decision guide to choose a proportionate one.

• If it is a person, add a named backup and write down the steps they would follow. Documentation reduces the risk of an AI champion leaving without a handover.
• If it is a personal account, replace it with a dedicated service account owned by the company, with the smallest permissions the task needs.
• If it is a document or dataset, keep one master copy with a named owner, and back it up in a way you have tested. See backup and restore for AI agents for what to save.
• If it is a model or provider, decide whether a second option is worth the added complexity. Sometimes the right answer is a defined degraded mode instead. The article on using more than one AI model covers when a second model pays off, and the piece on avoiding vendor lock-in covers how to keep your options open.
• If it is an external API, define what the agent does when the call fails: retry, queue, stop or hand over. Make that behavior explicit instead of leaving it to chance.
• If you cannot fix it now, accept it in writing. Record the owner, the reason and the date for the next review.

For each fix, also decide how you will notice a failure. A fallback you never trigger is worth little if the failure goes unseen. A simple alert on expired credentials or failed calls is often more valuable than a second supplier.

How does Be Human handle dependency mapping?

Be Human treats the dependency map as part of the first engagement. When defining the agent's role, the team lists the models, accounts, tools, documents and people the role needs, records the approval boundaries, and marks the single points of failure with the client. During managed operations, the map is reviewed alongside monitoring, permission review and integration maintenance, and changes to tools or access go through an agreed change process. The company keeps control of the accounts and decisions that belong to it, while the day-to-day checking is part of the managed work. For how responsibility is divided, see the shared responsibility model, and for the recurring routine, see what AgentOps involves.

Frequently asked questions

How often should I update the dependency map? Update it whenever the agent gains a new tool, a new data source, a new permission or a new owner, and review the whole map on a regular schedule your team can keep. A review that happens only after an incident is too late to be useful.

Who should own the map? A business owner or operations lead should own it, because the questions are about continuity and accountability, not only technology. Technical staff or your provider fill in details, but one named person should be responsible for keeping it current and acting on what it shows.

Do I need a separate map for each agent? Yes, at least at the start. Each agent has its own role, tools and documents, so its chain differs. Shared items, such as a common mailbox or model account, will appear on several maps, and that overlap is itself useful: it shows where one failure would affect many agents.

What if I find too many single points of failure to fix? Sort them by how soon you would notice a failure and how much damage it would cause, then fix the top few. Accept the rest in writing with an owner and a review date. A short, honest list that is being worked through is better than a long plan nobody follows.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.