Foundations for the agentic era: getting data, CRM and integration ready

This guide is for leaders and architects who want AI agents working in their business, and who want the systems underneath to hold up for decades. An agent is only as good as the data it reads, the access it inherits and the systems it can call. We've written down the foundations we look for first, with a short checklist you can run with your own team.

Why foundations come first

We think the businesses that thrive in 2050 will mostly be the ones making plain, durable choices now. Models and tools will change many times before then, and that's fine. What lasts is a clear record of who your customers are, data that someone owns, access rules that hold, and interfaces other systems can rely on.

Those choices help your people today, long before any agent arrives. They're also what every future agent will stand on. We think of this work as stewardship: you're building something the next team will inherit and run.

One trustworthy customer picture

People and agents should work from the same picture of a customer. When sales, service and billing each hold their own version, an agent will confidently repeat whichever one it finds first. That's how a customer gets a renewal offer the day after they cancelled.

Start by naming one system of record for each part of the customer: identity, contact details, consent, orders, cases and billing. The others can keep copies, but they should know where the truth lives. Match and merge duplicates with rules you can explain to a colleague, and keep a history of every merge so you can undo a bad one.

Store consent and contact preferences as structured fields that code checks before anything is sent. A note in a free-text box can't protect anyone. A CRM designed this way lets people and agents see the same history, the same promises and the same open issues.

Data quality with named owners

Every data set an agent will use needs an owner. That's a role, such as the head of customer operations, who decides what "correct" means and makes sure it gets fixed. Without an owner, a known problem can sit unfixed for months while each team assumes another will handle it.

Write short definitions for the fields agents will rely on. "Active customer" often means one thing in finance and another in support, and an agent will happily mix them up. A one-page glossary, agreed by the owners, heads off a lot of wrong answers before they happen.

Pick a few quality checks and show them where owners will see them: completeness, freshness, duplicates and whether values match their definitions. NIST's AI Risk Management Framework says accuracy measurements should be paired with clear, realistic test sets that represent the conditions of expected use. So build your agent's test data from the real shapes of your own records. We do this work on the platforms you already run, since readiness rarely requires a migration first.

Access controls agents inherit

When an agent acts for a person, it should inherit that person's access, not a broad service account's. OWASP's Top 10 for LLM Applications 2026 gives one example of excessive permissions: a tool that reads one user's documents through an account that can see everyone's. Its guidance is to run tools in the user's context and carry that context through chained agent calls.

Put record-level and field-level rules in the data layer, so they hold no matter which tool or agent is asking. For agents that run on their own identity, grant only what they need on day one and set a date to review it. The Model Context Protocol's security guidance takes the same line on scopes. Start small, grant more only when a privileged action first needs it, and avoid wildcard or all-access scopes.

APIs and events agents can call safely

Agents call the same interfaces your other systems do, so those interfaces need to be clear. The OpenAPI Specification describes HTTP APIs in a standard, language-neutral way that both people and computers can read without the source code. A good description is the raw material every agent tool is built from.

Offer small, specific operations, such as "add a note to this case". A single endpoint that can update anything gives an agent far more reach than its job needs. OWASP advises avoiding open-ended tools and defining a strict schema for every input, then validating it before use. Add rate limits and circuit breakers, because OWASP also recommends thresholds that halt, slow down or escalate an agent's calls when they're exceeded.

Make retries safe. Agents retry when a connection drops, and a retried "send invoice" shouldn't send two invoices. RFC 9110 defines an idempotent method as one where several identical requests have the same intended effect as a single request. Design your create and send operations so a repeat is recognised and ignored.

Publish the business events that matter, such as an order shipped or a case closed, in a common format. CloudEvents, a graduated project of the Cloud Native Computing Foundation, is a specification for describing event data in a common way. Events let agents and systems react to change without constantly polling your records.

Open protocols, named plainly

The Model Context Protocol is an open protocol for connecting AI applications to data sources and tools. It uses JSON-RPC 2.0 messages between hosts, clients and servers, and servers can offer resources, prompts and tools. Its current version is dated 2026-07-28.

The specification sets clear principles. Users must explicitly consent to data access and operations, and hosts must get explicit consent before invoking any tool. Tool descriptions should be treated as untrusted unless they come from a trusted server. It also says the protocol can't enforce these principles on its own, so the consent and authorisation flows are yours to build. Its security guidance forbids servers from accepting tokens that weren't issued to them.

OWASP adds a supply-chain view. It recommends pinning, signing and verifying every Model Context Protocol server and third-party tool package, and auditing tool descriptions for hidden instructions. Open protocols matter for the long run because they let you change models and vendors without rebuilding every connection.

Logging and audit

For every agent action, record who asked, which agent acted, which identity it used, which tools it called, what the code decided and what changed. Carry one correlation ID across systems, so a single request can be traced from start to finish. The Model Context Protocol's security guidance recommends logging permission elevations with correlation IDs, and it warns that passing tokens through muddies audit trails.

NIST's Generative AI Profile notes that logging, recording and analysing incidents makes it easier to share what happened. It adds that change records and version history help the people responding. Keep logs under clear retention rules, and don't record more personal data than the investigation will need.

Accessibility is part of the foundation

Agents reach people through chat windows, forms, emails and voice, and everything a person sees or hears should work for everyone. WCAG 2.2 from the W3C is the reference we use, and we aim for level AA. It was first published in October 2023, and the current Recommendation is dated 12 December 2024.

Several of its criteria speak directly to agents. Consistent Help lists a fully automated contact mechanism, such as a chatbot, among the help features that should appear in the same relative order wherever they're repeated. Redundant Entry says information a person already gave earlier in a process should be filled in or offered again. That's exactly what a good handoff does. The EU AI Act's transparency article also says AI disclosures must meet the applicable accessibility requirements. We check with automated tests and by hand, with a keyboard and a screen reader.

A short readiness checklist

  • Each part of the customer record has one named system of record, written down.
  • Every data set an agent will use has an owning role and a short glossary for its key fields.
  • Consent and contact preferences are structured fields that code checks before anything is sent.
  • Agents acting for people inherit those people's access, and agent identities have only the scopes they need.
  • Record-level and field-level access rules live in the data layer.
  • APIs are described in a machine-readable format, operations are specific and inputs are validated.
  • Create and send operations are safe to retry, with rate limits in place.
  • Key business events are published in a common format.
  • Every protocol server and tool is approved, pinned and reviewed, and tools run only with consent.
  • Every agent action is logged with an identity, a correlation ID and an outcome, under set retention.
  • Everything an agent shows people meets WCAG 2.2 level AA, checked automatically and by hand.
  • Someone owns a review of this list at least twice a year.

Sources