Part 1 makes the uncomfortable point: AI does not repair unresolved integration debt simply because it can search across it.

Read Part 1: voipguru.org

The next question is practical.

How do I use AI to help people work through that debt without letting the agent invent a common truth, inherit excessive authority, or act before the organization understands what it is connecting?

I start with two boundaries: what the agent is allowed to know, and what it is allowed to do.

They are not the same boundary.

Start with an evidence register, not a giant context window

A large context window is not a governance model.

Before asking an agent to compare acquired systems or processes, I would create an evidence register. Each source should carry enough information for a reviewer to understand why it belongs in the task:

  • Source name and location.
  • Business owner.
  • Effective date and review date.
  • Scope and intended use.
  • Sensitivity and handling rules.
  • Systems, products, customers, or regions it applies to.
  • Whether it is authoritative, supporting, historical, or unverified.
  • Known conflicts and superseding sources.
  • Who approved its use for this analysis.

This is slower than pointing the agent at every available file. It is much faster than correcting a confident recommendation built from the wrong policy, an obsolete diagram, and a spreadsheet nobody owns.

NIST's Generative AI Profile recommends tracking the provenance and history of inputs, documenting limitations, and connecting technical evaluation with organizational accountability. Provenance does not prove that a source is correct, but it allows people to see where an answer came from and challenge it. (nvlpubs.nist.gov)

Limit retrieval to the intersection of three things

For each task, I would limit retrieval to the intersection of:

  1. What the requesting person is authorized to access.
  2. What the agent is authorized to access.
  3. What the task actually requires.

If a source fails any one of those tests, it stays out.

That matters because an agent can combine individually ordinary records into a result that is more sensitive than any one source. It also matters after acquisitions, when inherited permissions, shared repositories, and broad service accounts may reflect yesterday's organization rather than today's authority.

The Australian Signals Directorate describes the agentic harness as the layer connecting the model to context, memory, data, tools, permissions, and actions. Its guidance emphasizes least privilege, strong identity, controlled tools and data, output validation, human oversight for high-impact activity, continuous monitoring, and controls enforced outside the model. (cyber.gov.au)

The model can request evidence. The harness decides whether the request is permitted.

Ask AI to preserve disagreement

The first useful prompt is not “give me the unified answer.”

It is closer to this:

Using only the approved sources, identify every definition of this term. For each definition, list the exact source, owner, effective date, scope, dependent systems, and known exceptions. Do not reconcile conflicts. Mark missing evidence as unknown.

That instruction is simple, but the surrounding controls are what make it reliable. The system must restrict retrieval to approved material, preserve source references, and prevent retrieved content from expanding the agent's authority.

The next prompt can compare without deciding:

Create a contradiction table. Show where definitions, permissions, customer promises, process steps, controls, and success measures disagree. Separate documented facts from inference. For every inference, state what evidence would confirm or reject it.

The goal is not to make the disagreement disappear. The goal is to make it reviewable.

Map authority beside the process

Most integration diagrams show systems and data flows. I also want an authority map.

For each consequential step, it should show:

  • Who owns the business decision.
  • Who owns the system.
  • Who can approve access.
  • Who can change the process.
  • Who handles an exception.
  • Who verifies the result.
  • Who is accountable when the handoff fails.

An AI agent may help draft that map from approved evidence. It should not assign authority because a job title sounds plausible.

I would prompt it this way:

Build a candidate authority map from explicit statements in the approved sources. Do not infer an owner from organizational position alone. Mark every missing or conflicting owner for human resolution. Do not recommend execution authority until the owner, scope, and escalation path are confirmed.

This is where a lot of attempted automation exposes the real problem. The workflow is not blocked because the model lacks intelligence. It is blocked because the organization never decided who owns the crossing.

Put the control boundary outside the model

Instructions such as “ask before changing anything” are useful, but they are not sufficient controls.

The harness should enforce:

  • Named user and agent identities.
  • Task-specific, time-limited permissions.
  • Approved tools and destinations.
  • Data classification and transfer rules.
  • Read-only discovery before write access.
  • Exact action previews for consequential changes.
  • Human authorization before execution.
  • Verification after execution.
  • Immutable records of source, proposal, approval, action, and result.
  • Revocation, rollback, and shutdown paths.

The human decision needs to occur before the consequential boundary. If the system writes the file, changes the permission, sends the data, or starts the workflow before approval, the person is being notified after the fact.

NIST's AI Risk Management Framework and Playbook encourage organizations to define roles, document oversight, track exceptions, measure outcomes, and retain the records needed to evaluate whether controls work in practice. (nist.gov) (nist.gov)

Turn contradictions into decisions people can own

Once the evidence and authority maps exist, AI can help prepare decision packets.

For each unresolved item, I want a compact record containing:

  1. The decision that must be made.
  2. The conflicting evidence.
  3. The affected customers, systems, teams, controls, and reports.
  4. The available choices.
  5. The risk and cost of each choice.
  6. The person or group authorized to decide.
  7. The test that will show whether the decision worked.
  8. The rollback or review condition.

The agent can draft the packet and identify missing information. People decide which definition, process, access path, or exception the organization will own.

The result then becomes governed evidence for the next step. It should not remain buried in a chat transcript.

Use Business Intelligence to check the integration

An agent completing more tasks is not proof that the underlying integration improved.

I would connect the approved integration map to measures such as:

  • Customer handoff failures.
  • Time to resolve exceptions.
  • Duplicate or contradictory records.
  • Access exceptions and emergency overrides.
  • Manual recovery work.
  • Reopened incidents.
  • Definition changes after review.
  • Agent proposals rejected or narrowed by people.
  • Verification failures and rollbacks.
  • Customer effort, service reliability, and support outcomes.

The measurements must use the same governed definitions the integration work established. Otherwise, the dashboard becomes another conflicting system.

Google's DORA research describes AI as an amplifier and finds that the surrounding organizational system strongly influences the result. Faster output without the capabilities to review, test, and recover can increase instability. (dora.dev) (dora.dev)

Business Intelligence closes the loop by showing where the proposed integration worked, where it moved the problem, and where a human decision still has not reached the process.

This is where I can help

This work sits between architecture, operations, security, Customer Experience, and Business Intelligence.

It requires someone willing to follow the customer outcome across organizational lines, compare what the documents say with what the systems actually do, identify the hidden permission and ownership gaps, and turn the findings into something leaders and engineers can act on together.

AI makes that work faster. It can search, compare, organize, trace, and test at a scale that would be difficult manually.

I use it to make the evidence clearer, not to make the accountable person disappear.

The sequence matters:

  1. Approve the evidence.
  2. Preserve the disagreements.
  3. Map the authority.
  4. Resolve the decisions.
  5. Constrain the tools.
  6. Authorize the action.
  7. Verify the result.
  8. Measure the outcome.

That is how an organization can move from AI layered over integration debt to agentic engineering grounded in evidence, permission, human judgment, and measurable results.