Agentic MarTech and Its Invisible Architecture

Every arrow in a MarTech diagram was a boundary somebody had to own. Agentic interfaces are collapsing those arrows into a text box, but the boundaries have not disappeared. They have moved into tool permissions, prompts, semantic definitions, retrieval policies, approval rules and traces. A conversational surface is safe to adopt only when somebody can still answer five questions about anything it produces: identity, consent, provenance, constraint and record of outcome.

For years, MarTech diagrams told part of the truth through their arrows. An arrow showed that customer data had to move, that two platforms needed to agree on identity, that latency would enter somewhere and that a team would eventually own the connection.

Those arrows were not decorative. They represented decisions, and their visibility made those decisions difficult to avoid.

Many of the arrows are now disappearing from the interface. The simplification is useful, because most marketers should not have to operate five systems manually before they can build an audience or launch a journey. The problem begins when removing the need to operate the architecture also removes the ability to inspect it.

Every arrow was a governance decision

An arrow between a CDP and a CEP was never merely a line showing that data moved from one box to another. It was where an organisation had to decide which system held the customer record, which one calculated the audience, how identity was resolved, where consent was checked and what happened when the two systems disagreed.

The same was true elsewhere. An arrow from a CRM carried decisions about relationship status and eligibility. An arrow from a warehouse carried definitions, model scores and latency. An arrow into a content platform carried approval, rights and versioning. An arrow into a delivery system carried responsibility for pressure, suppression and execution.

These questions acquired owners because somebody had to build and monitor the connection, and the connection announced itself whenever it failed. A failed audience transfer produced an alert, a late file had an SLA, and a schema change broke a job and forced a conversation. The diagram was a governance artefact disguised as a technical drawing.

The drawing never captured everything, and it certainly did not record why a marketer chose one definition rather than another. It still exposed enough structure for an experienced person to ask where authority lived and enough continuity for a new colleague to learn the shape of the stack.

The interface became simpler, not the architecture

A traditional application revealed part of its internal model. A campaign builder showed audiences, steps, branches, channels and status, a CRM showed accounts, contacts, opportunities and cases, and a CDP showed identities, attributes, segments and destinations. The interface was not the architecture, but it leaked the architecture.

A conversational interface can conceal almost all of it. The user sees a text box and asks for an outcome: identify customers at risk of leaving, exclude anyone with an unresolved complaint, choose the right channel, create the message, launch the journey and explain what happened.

That one request may touch a warehouse, CRM, CDP, content system, decision engine, engagement platform, several models and an agent runtime choosing which tools to call. The architecture has not become smaller. It has been compressed into the conversation.

The compression is attractive for the same reason graphical interfaces were attractive. It reduces the operational knowledge required to perform useful work. What changes is the evidence left in front of the operator. When a marketer builds an audience in a segment builder, the definition is visible and can become a persistent object. When the marketer asks an agent for the best audience, the answer may be better, but the route to it can become invisible.

A coherent answer is not evidence of a coherent customer model.

The result may combine a propensity score from the warehouse, eligibility from the CRM, recent behaviour from the CEP and an assumption introduced by the agent. It arrives in one voice even when the systems behind it do not share one definition of the customer.

Three agentic postures, three levels of risk

Vendor announcements often describe every conversational capability as an agent, although the persistence and authority behind those interfaces differ materially. Product documentation available in 2026 shows three useful postures.

The first treats the conversation as the place where the marketing object is constructed. Salesforce describes marketers drafting, refining and generating multichannel campaigns through Agentforce, while Bloomreach’s Loomi marketing agent can turn a prompt into a built campaign workflow. This posture removes the most operational effort, but it creates the largest inspectability question: does the audience, rule or journey survive as a versioned object, or does only the result and its conversation remain?

The second uses conversation to operate a persistent model. Braze’s Operator can create or update a Canvas or Campaign, but the Canvas and Campaign remain objects inside Braze. Adobe’s Journey Agent can analyse conflicts and fallout or create structured journeys from natural language, while the journey remains part of Journey Optimizer and subject to product permissions. The conversation accelerates the platform instead of replacing its model.

The third points the agent at the customer. Insider’s current Agent One documentation describes Shopping and Support agents that conduct customer-facing conversations. Their accountability problem is different because the agent is not only helping a marketer construct a workflow. It is participating in the customer experience and may call external services through configured API endpoints.

These postures are not maturity levels, and none is automatically good or bad. They expose different risks: an agent that recommends needs provenance, an agent that constructs needs persistent definitions and review, and an agent that acts needs enforceable authority, escalation and a durable record.

The distinction also protects a buyer from agent washing. Gartner estimated in June 2025 that only about 130 of the thousands of vendors claiming an agentic label were offering genuinely agentic capabilities. Forrester predicted that fewer than 15 percent of firms would enable agentic features in intelligent automation suites during 2026, while its June 2026 assessment found broad adoption intent but only a small minority running meaningful production systems beyond agent-like chatbots. The tooling has moved faster than the operating model.

The test that matters during platform selection

The most informative test does not require an analyst framework.

Build an audience, journey or campaign in the conversation. Close the conversation. Return the next morning as a colleague who was not present, then inspect what remains.

If the colleague can open a journey, Canvas or segment, inspect its definition, see its version, change it and understand its approval state, the conversation was an accelerator over a persistent model. If the colleague finds a transcript, an output and no reusable object that explains how the population or decision was formed, the conversation was the model.

The second outcome is not necessarily disqualifying. A genuinely one-off analytical request may not need a permanent campaign object. It does require a deliberate answer about what will be retained, how the result can be challenged and whether the agent had authority to act on it.

The test therefore has a second part. Ask the vendor to show the definition used, the population produced at execution time and the trace that connects the two. Those are three different artefacts.

A versioned definition records intent: what at-risk meant, which exclusions applied and which policy version was active. An execution snapshot records the population produced by that definition at a particular time. A trace records how the agent retrieved data, interpreted instructions, called tools and moved from the first artefact to the second. None can replace the other.

Where the missing arrows went

Once conversation becomes the entry point, the boundaries move into a different set of artefacts.

Take a request that sounds straightforward: “Launch a winback campaign for at-risk customers this week, and leave out anyone with an open complaint.”

Tool permissions decide which systems the agent can reach and which operations it can perform. The current Model Context Protocol specification makes the importance of this boundary explicit by treating tools as paths to data access and code execution, and by requiring authorization controls for protected HTTP resources. Connecting a tool is not merely technical plumbing. It defines the agent’s reachable authority.

Prompts and agent instructions carry intent, behavioural policy and procedural guidance. They are valuable, but a sentence in a prompt is not automatically a control. “Leave out anyone with an open complaint” remains an instruction until a system enforces it against a current complaint record.

Semantic definitions determine what at-risk means. The score might represent churn probability, inactivity, declining value or a commercial segment with the same name. The agent can use the label fluently without knowing that two teams use it differently.

Retrieval policies determine which evidence reaches the model. If the service system is outside the retrieval scope, the unresolved complaint does not appear as missing data. It simply fails to influence the answer.

Agent identity and approval rules determine whether the system recommends, drafts, modifies or publishes. A human approval step matters only when the reviewer can see enough of the decision to challenge it.

Traces record the path through those boundaries. They can capture model calls, retrieved context, tool invocations, parameters and results, but they are evidence of execution rather than a business definition. OpenTelemetry’s current generative AI conventions already support structured spans for agent invocation, model calls and tool execution, including optional capture of prompts and results. The technical raw material for better auditability is arriving. Retention, access, redaction and business ownership remain organisational choices.

Figure 1. The boundaries moved from visible connections into runtime configuration and evidence.

This is why a simplified product diagram can describe a system that is harder to govern. The new arrows do not usually appear on the diagram at all.

Could traces make the system more auditable?

There is a strong objection to the argument so far. Graphical interfaces exposed structure but rarely exposed rationale. A segment builder retained its filters and did not record why those filters were chosen, which attributes were rejected or what commercial risk the exclusion was meant to prevent. An agent run can be traced from request to outcome.

On that reading, the conversational surface does not reduce auditability. It creates the first realistic opportunity to capture reasoning, retrieval and tool use together.

The objection is right about the opportunity. OpenTelemetry is standardising the technical representation of generative AI and agent operations, while emerging work such as the OWASP Agent Observability Standard is trying to extend established telemetry and security-event models to agent decisions. NIST’s AI Risk Management Framework already treats documented, continuous governance, measurement and monitoring as lifecycle responsibilities rather than deployment tasks.

The limitation is that a trace answers what happened in one execution. It does not create a shared business definition, prove that the definition was correct or certify that a natural-language instruction became a binding rule.

The old segment definition also needs to be described more carefully than it often is. A query is not the same thing as its audience, because the population changes as data changes. Inspectability requires both the versioned definition and an execution-time snapshot. The agent trace then records how those artefacts were used and which other systems influenced the action.

This produces a more demanding but more accurate chain:

Intent lives in the definition. Application lives in the snapshot. Execution lives in the trace. Enforcement lives in the control.

Current practice frequently retains traces as short-lived engineering diagnostics. Even a technically complete trace may be inaccessible to the marketing owner, contain sensitive prompt or customer data, or disappear before an audit or complaint arrives. Better tooling can solve much of that, but only after the organisation decides which traces are business records, how long they survive and who is allowed to read them.

Traces are therefore not the missing architecture. They are the most promising evidence that the hidden architecture can be reconstructed.

Five questions for any agent-produced outcome

The practical response is not to reject conversational interfaces or require marketers to understand every integration. It is to keep the outcome answerable.

For any material action produced by an agent, somebody in the organisation should be able to answer five questions.

Identity. Which system supplied the customer identity, and which graph or matching rule resolved it?
Consent and eligibility. Which system provided the current consent and eligibility state, and when was it evaluated?
Provenance. Where did the score, ranking or definition come from, and which version was used?
Binding constraint. Which rule could actually block or modify the action, and which system enforced it?
Record of outcome. Which persistent object, execution snapshot and trace allow the decision to be reconstructed later?

Five inspectability questions mapped to the evidence needed for each one: source of identity, live eligibility, versioned definition, enforcing control, execution snapshot and trace.

Figure 2. Inspectability depends on a chain of evidence, not on the conversational answer alone.

Apply the questions to the winback request and the gaps become concrete. Identity may come from the CDP, while the at-risk score comes from the warehouse. Consent may have been checked when the audience was created, although the complaint exclusion needs a live service-system lookup at execution. The sentence in the prompt expresses the policy, but only an eligibility service or enforced exclusion can bind it. The campaign records what was sent, the population snapshot records to whom, and the trace records how the agent assembled and executed the decision.

An unanswered question points toward a missing artefact or owner. That is more useful than a general concern about black-box AI because it identifies what has to change.

Replace the diagram with an agent register

Traditional architecture inventories integrations, systems and data flows. Agentic architecture needs an additional register organised around authority.

One row per agent is enough to begin. Record the business purpose, owner, tools it may call, data and semantic definitions it relies on, retrieval scope, actions it may take without approval, binding controls, escalation path, persistent objects it creates, trace location and retention period.

The register should distinguish permission from policy. Permission says the agent can update a campaign, policy says under which conditions it may do so, and a control says what prevents it from acting outside those conditions. The three are often collapsed in product demonstrations because the happy path makes them look equivalent.

Example agent register for a winback agent, recording its purpose, tools, semantic definitions, retrieval scope, unattended actions, binding controls, escalation, trace retention and named owner.

Figure 3. The agent register makes authority reviewable even when the interface hides the execution path.

The register is intentionally dull. It can be reviewed by a steering group, handed to a risk function and used during platform selection. It also forces a useful question whenever a new tool is connected through MCP or another agent interface: which row changed, which authority expanded and which control now covers it?

This is the operational companion to the commercial test I use when judging agentic marketing claims. A vendor that cannot populate the row for its own agent is demonstrating fluency, not architecture.

Fluency is not architectural coherence

A single interface creates the impression of a single system. Several customer models sound like one, several decision layers appear coordinated and several governance regimes feel consistent because the answer arrives in one voice.

Articulacy is a poor proxy for correctness.

This matters wherever the four gravities shaping MarTech decisions meet. The suite, CRM, enterprise data layer and engagement runtime can each have a defensible claim to part of the customer decision. Putting all four behind one conversational surface does not resolve that ownership question. It removes the evidence that the disagreement exists.

Gartner’s prediction that more than 40 percent of agentic AI projects will be cancelled by the end of 2027 cited escalating cost, unclear value and inadequate risk controls. None is principally a model-quality problem. Each concerns the system and operating model around the model.

The arrow has not gone away. It has moved into permissions, definitions, retrieval, controls and traces, where fewer people can see it and responsibility is easier to diffuse.

Simplify the interface as much as you like, but keep the architecture answerable.