Your Marketing Agent Needs a World, Not Another Prompt: Building Marketing Agentic Systems the Palantir Way

Your marketing agent looked intelligent until the user asked it to do real work.

The request was ordinary:

Review the live setup of our summer prospecting campaign against the client’s approved campaign requirements.

The agent understood the words. It knew what a campaign setup review was. It could explain prospecting, frequency caps, audience exclusions, bid settings, creative rotation, and brand safety. It could search the client’s requirements library. It could call an advertising API.

Then the simple sentence began to split apart.

Which summer prospecting campaign? There were three with similar names. Which platform? Which advertiser account? Were the campaign requirements current and approved, an old project brief, or general guidance? Did “review” mean inspect the live setup, retrieve an existing audit, or recommend changes? If a setting was absent from the API response, did that mean it was wrong, unavailable, inherited, or never checked?

The model could guess. A fluent guess would make the problem harder to see.

This is the hidden difficulty in building marketing agents. Models are becoming better at language, interpretation, planning, and tool selection. Marketing work remains spread across platforms, constantly changing, governed by access rules, and full of names that look more precise than they are.

A larger prompt can explain more rules. It cannot prove which campaign exists. It cannot establish who owns it. It cannot make an incomplete API response complete. It cannot turn a document title into approved policy. It cannot create permission to change a budget.

The agent needs a world it can reason inside.

Your Marketing Agent Needs a World, Not Another Prompt: Building Marketing Agentic Systems the Palantir Way

The Missing Middle

Our earlier guides described the visible parts of an agentic system.

Skills hold reusable procedures. Agents interpret requests and coordinate work. Tools, MCP servers, and CLIs connect the model to data and software. A harness the control software around the model manages context, memory, workflow stages, retries, and limits. Policies constrain risky behaviour.

These components are necessary. They still leave a gap.

Suppose an agent has a tool that retrieves campaign data. The tool needs a campaign ID. The user supplies “summer prospecting.” The model sees campaign names in a search result and chooses one. Technically, every component worked:

the model interpreted the request;
the skill selected the correct procedure;
the tool returned a valid response;
the advertising platform accepted the ID;
the access rules permitted the read.

The system may still have inspected the wrong campaign.

The missing layer connects human meaning to operational reality. It answers questions such as:

What objects exist in this business process?
Which identities persist across tools and conversations?
How are those objects related?
Which system can prove each relationship?
What may happen to each object?
Which evidence is required before an action?
Who can approve the action?
What observation proves the result?

Call this an ontology, an operational model, or simply a working model of the business. The name matters less than the job. It gives the agent a coherent representation of the world between the prompt and the API.

Without it, the model reasons over strings. With it, the model can reason over campaigns, requirements, evidence, available operations, decisions, and outcomes whose identities and relationships survive beyond one response.

System map

The world around an agent

Reasoning becomes useful when it is connected to real business objects, trusted evidence, controlled action, and feedback. Select any idea to trace its dependencies.

Focus an idea

PurposeAgent intelligenceBusiness worldTrust and controlActionLearningSignificance 6–10

Operational business world10/10 significance

A connected working model of campaigns, requirements, evidence, actions, and outcomes.

Marketing example: The agent reasons over a verified campaign, its account, requirements, live settings, and measured results.

Direct connections

Agent interpretation and planning reasons through Operational business world
Operational business world contains Business objects
Operational business world connects through Proven relationships
Operational business world makes available Meaningful actions
Operational business world generalises through Cross-platform business roles

Circle size expresses each idea’s structural significance in this article; it is an editorial map, not an empirical score.

View every idea in significance order

Customer and business purpose — 10/10. The outcome the whole system exists to improve; every other idea should trace back to it.
Operational business world — 10/10. A connected working model of campaigns, requirements, evidence, actions, and outcomes.
Trusted evidence — 10/10. Facts remain tied to the system that can prove them, including source, scope, and freshness.
Access and approval — 9/10. Access rules and exact approvals decide which information and effects are allowed.
Agent interpretation and planning — 9/10. The model interprets fuzzy language, forms hypotheses, chooses evidence, and explains decisions.
Business outcome feedback — 9/10. Observed results return from platforms, commerce, CRM, and customers to improve the next decision.
Controlled action — 9/10. Live reads and changes are limited to confirmed objects, permissions, budgets, and approvals.
Platform-specific identity — 9/10. The platform-issued ID and account placement determine the exact live object involved.
Whole-system correctness — 9/10. The complete workflow must remain safe, useful, recoverable, and accurate when its individually correct parts interact.
Agent control layer — 8/10. The harness manages context, memory, workflow stage, retries, cancellation, budgets, and recovery.
Approved requirements source — 8/10. Client requirements retain their document, version, exact passage, client, and effective date.
Business objects — 8/10. Campaigns, audiences, creatives, requirements, experiments, and outcomes become stable things the agent can reason about.
Cross-platform business roles — 8/10. Shared roles support reasoning across channels while every platform keeps its own object types and operations.
Evidence plan — 8/10. A review plan binds the confirmed campaign, requirements, available operations, coverage, and limits.
Findings and coverage — 8/10. Each requirement is reported as matched, a gap, not evaluated, or unavailable, with complete or partial coverage.
Human judgment — 8/10. People resolve genuine ambiguity, value choices, exceptions, and consequential approvals.
Independent reconciliation — 8/10. Platform conversions are checked against browser, server, CRM, order, return, and retention evidence.
Meaningful actions — 8/10. The model sees business operations instead of a bag of raw commands.
Proven relationships — 8/10. Connections such as campaign-to-account or creative-to-brand are explicit and verifiable.
Requirement interpretation — 8/10. The model interprets the intention of natural-language requirements without replacing the original source.
Usable autonomy — 8/10. The agent should reason freely, ask fewer unnecessary questions, and remain unable to invent facts or authority.
Focused clarification — 7/10. The agent asks only when several verified choices remain plausible or human judgment is truly needed.
Signal ownership — 7/10. The system records who collects, controls, receives, retains, and uses each marketing signal.
Tools and platform connectors — 7/10. APIs, MCP servers, and other connectors perform the approved reads and changes.
Reusable skills — 6/10. Skills give the agent repeatable procedures without becoming a source of permission or truth.
Share of Choice — 6/10. Evaluation follows retrieval, recommendation, selection, transaction, completion, and reuse across agent-mediated tasks.

What Palantir Saw

Palantir’s Ontology is useful here because it makes a strong claim than most systems give data consistent business meaning.

The Foundry Ontology overview describes an operational layer that connects data and models to their real-world counterparts. Its “semantic” elements describe what things are and how they relate: objects, properties, and links. Its “kinetic” elements describe what can happen: actions, functions, and security.

That final group changes the idea.

A conventional semantic layer gives data a consistent business meaning. Revenue means the same thing across dashboards. A customer table joins to an order table through an agreed key. This is valuable. It remains mostly descriptive.

An operational ontology also represents what can happen.

An order can be approved. A machine can be taken out of service. A shipment can be rerouted. The action has inputs, permissions, conditions, and consequences. Logic connects the decision to operational systems. Security follows the objects and actions rather than sitting as a separate paragraph in a governance document.

Palantir’s architecture documentation frames this as the integration of data, logic, action, and security. Its core concepts distinguish object types, properties, links, actions, functions, and interfaces. The ontology becomes a model of how an organisation sees and changes its world.

Marketing needs the same shift in perspective.

We have spent years building data layers around impressions, clicks, costs, conversions, audiences, and creative assets. We have built taxonomies, naming standards, warehouse schemas, dashboards, attribution models, and platform connectors.

Agents introduce a different requirement. The system must understand that a campaign is more than a row, that a client rule is more than a document chunk, and that a budget recommendation is more than generated text. Each belongs to a chain of identity, evidence, permission, decision, and effect.

The spreadsheet described the campaign. The agent may now act upon it.

A Marketing World Has Nouns and Verbs

A marketing ontology often begins with familiar nouns:

Object	What it represents
Brand	A governed commercial and creative identity
Customer task	A goal or situation someone is trying to complete
Campaign	A marketing initiative as represented inside its advertising platform
Delivery unit	The platform-specific level where targeting, bidding, or delivery operates
Creative	A versioned asset and its claims, rights, format, and approvals
Audience	A defined eligibility or modelling construct with a known source and restrictions
Requirements source	A versioned client, legal, platform, or brand requirement
Evidence result	A result returned by the trusted system for that fact
Experiment	A hypothesis, design, treatment, measurement plan, and decision state
Business outcome	An order, qualified lead, margin contribution, retention event, return, or other real result

The relationships carry much of the meaning.

A campaign belongs to an advertiser account. A delivery unit belongs to a campaign. A creative is approved for a brand, market, placement, and period. A requirement applies to a client and perhaps a narrower channel or campaign type. An observation came from a particular advertising-platform operation at a particular time. A conversion may link to an order, which may later link to a return.

Then come the verbs:

resolve a campaign;
inspect live targeting;
interpret an individual requirement;
compare evidence with a requirement;
propose a budget change;
preview the effect;
approve a plan limited to a named campaign, period, and budget;
execute a change;
reconcile the observed result;
amend or roll back the plan.

Each verb needs more than a function name. It needs a target, conditions, permission, limits, a clear account of what failure means, and evidence.

This is where an ontology becomes operational. The agent no longer sees a bag of tools. It sees meaningful operations attached to real business objects under explicit conditions.

Those objects and operations solve the missing middle. They do not make the whole agent.

The Whole Marketing Agent System

The working model of the business belongs inside a larger system. Seeing that whole first makes the responsibilities easier to separate.

PURPOSE
customer and business outcomes
        ↓
AGENT
interpretation, hypotheses, planning, explanation
        ↓
AGENT CONTROL LAYER (HARNESS)
context, memory, state, budgets, retries, workflow stages
        ↓
SKILLS
marketing procedures and domain guidance
        ↓
OPERATIONAL MODEL
objects, relationships, available operations, actions
        ↓
TRUST AND CONTROL
verified identity, sources, permissions, fixed rules, approval
        ↓
EXECUTION
APIs, MCP servers, CLIs, jobs, transactions
        ↓
REAL WORLD
campaigns, customers, platforms, teams, organisations
        ↺
observations, feedback, reconciliation, evaluation

Each layer owns a different problem.

Purpose decides what success means. The agent makes sense of the request. The harness, the agent’s control layer, keeps the work coherent across time. Skills provide reusable ways of operating. The operational model tells the agent what exists and what can happen. Trust and control decide which claims can be relied upon and which actions are allowed. Execution touches external systems. Observation returns evidence from the world.

Weak systems compress these layers.

A skill becomes a permission system because its instructions say “allowed.” A tool response becomes truth because the request succeeded. A memory summary becomes current state. A dashboard metric becomes the customer outcome. A human approval becomes reusable permission for a different campaign. An object in the working model becomes valid for a live API call simply because it contains something that looks like an ID.

Strong systems keep the layers connected without allowing one to impersonate another. That separation begins with the most important distinction in the article: understanding a request and proving facts about the world are different jobs.

Understanding and Proof Are Different Jobs

The current debate around marketing agents often begins with a reasonable challenge: if the model is intelligent enough to understand the user, why surround it with so much structure?

Because understanding and proof answer different questions.

The model may be the best component for interpreting “the campaign we launched before Wimbledon.” It can use conversation history, naming patterns, dates, and context to form likely candidates. A deterministic router built from keywords will often do worse.

The advertising platform can confirm whether a campaign exists in the selected account. Client access controls determine whether the user may see it. The approved requirements library tells the agent which rules are current. The control software decides whether a particular read or change is allowed. A person decides when the choice is genuinely ambiguous or consequential.

These responsibilities can coexist:

Responsibility	Best owner
Interpret language and context	Model
Form hypotheses and compare candidates	Model
Confirm the exact platform record and where the campaign belongs	Advertising-platform connector
Validate the required data, limits, and workflow stage	Control software
Confirm where a requirement came from and whether it is approved	Governed requirements library
Decide which actions are allowed and how far they may reach	Access and approval rules
Resolve genuine preference or approve impact	Human
Perform the read or change	Approved tool action
Record coverage and real-world outcome	Observation and evaluation layer

The architecture gives the model freedom above a small set of rules that must always hold. It can decide which evidence is relevant, which tool to use, what order to investigate, and whether a contradiction needs further analysis. It cannot invent which account owns a campaign, which requirements are current, whether a user has permission, or whether a change actually happened.

As models improve, the reasoning layer should become less rigid. Unnecessary clarifications should fall. Tool selection should become more efficient. Recovery should become more intelligent.

Access to one client’s data should not become a matter of probability.

Those divisions sound abstract until they are applied to the request that opened the article.

From a Fuzzy Request to a Trustworthy Review

Return to the original request:

Review the live setup of our summer prospecting campaign against the client’s approved campaign requirements.

A coherent system can preserve the ambiguity without becoming paralysed by it.

User request
    ↓
Agent interprets the likely intent
    ↓
Campaign reference + requirements reference
    ↓
Verified search within the approved account
    ↓
Confirmed campaign + verified account relationships
    ↓
Requirements linked to their exact source
    ↓
Approved evidence plan + limits
    ↓
Live advertising-platform evidence
    ↓
Per-requirement findings + declared coverage
    ↓
Explanation, next decision, and retained evidence

1. Preserve the user’s words

“Summer prospecting” begins as a reference. It may contain a name, alias, date clue, platform hint, or account hint. It is useful. It is not yet enough to identify a campaign safely in a live system.

The same applies to “approved campaign requirements.” The phrase may point towards a source. It does not prove approval, freshness, which client or account it applies to, or its effective date.

2. Confirm against the real systems

The agent can propose search terms and likely campaign types. An advertising-platform connector searches only inside the account the user is allowed to access.

If the connector finds one complete match and all the available clues fit, the workflow can continue automatically. If two plausible campaigns remain, the agent asks a focused question. If the search results are incomplete, it asks the user to narrow the request rather than presenting a partial list as complete.

Once found, the campaign keeps the client account, advertising platform, platform object type, platform-issued ID, and confirmed place inside the account structure. A readable name helps the conversation. The platform-issued identity controls the API call.

3. Select the right source of rules

The system distinguishes client requirements from project briefs, general guidance, live campaign settings, historical audits, and derived summaries.

An approved client knowledge source can state what the campaign should do. It cannot prove what the campaign currently does. The platform can report current state. It cannot decide what the client intended. A previous audit can show an earlier evaluation. It cannot silently certify today’s setup.

4. Build an evidence plan

The model interprets each requirement and proposes what evidence would test it. The control software checks whether the available operations support this type of campaign, whether the source belongs to the selected client, whether the review can cover a clearly defined set of objects, and whether the total amount of work stays within its limits.

Only then is the review ready to run.

5. Preserve incomplete outcomes

Each requirement receives an explicit result:

observed match;
observed gap;
not evaluated;
source unavailable.

Coverage is complete or partial. A missing response does not become a pass. An unavailable field does not become a failure. A successful tool call does not prove that the evidence population was complete.

The final answer can now sound simple because the system did the difficult work underneath:

I reviewed campaign “Summer Prospecting 2026” in the selected advertiser account against seven rules from “Approved Campaign Requirements,” version 4. Two settings match, three have observable gaps, one could not be evaluated because the advertising platform does not make inherited brand-safety settings available through this operation, and one rule appears to conflict with the current market exception. No changes were made.

Fluency is useful again. It sits on evidence.

The review works because the system preserves three boundaries while moving from language to action. Interpretation remains attached to its source. Human judgment enters only where verification runs out. Cross-platform reasoning never erases the identity required for live work.

Three Boundaries Keep the World Honest

Meaning Must Stay Linked to Its Source

Client rules are rarely written as instructions a machine can apply directly.

They arrive in presentations, spreadsheets, emails, documents, tables, screenshots, and sentences shaped by people who already understand the context. They contain abbreviations, exceptions, examples, category language, and assumptions that no API structure can see.

Consider a rule such as:

Avoid excessive repetition and keep prospecting frequency appropriate for the audience and campaign objective.

A literal engine struggles because “excessive” and “appropriate” are contextual. A language model can interpret the intention: protect user experience and prevent waste caused by repeated exposure. It can identify likely evidence such as frequency distribution, reach, recency, audience size, campaign objective, creative rotation, and perhaps marginal response by exposure count.

That interpretation should remain linked to the source sentence.

The system needs five separate things:

Trusted source - which document, client, version, and exact passage contain the rule.
Interpretation - what the agent believes the rule intends.
Evidence requirement - what observations could support or challenge the interpretation.
Observation - what the trusted platform operation returned for the confirmed campaign.
Finding - how the evidence relates to the interpreted requirement, including uncertainty and coverage.

Collapsing these stages creates quiet failure.

If the model’s interpretation becomes the rule, the source can drift without anyone noticing. If the rule becomes evidence, the system may claim compliance without inspecting the campaign. If a live setting becomes policy, the current configuration can justify itself. If a prior finding enters memory as fact, yesterday’s conclusion can survive after the campaign changes.

The model should be allowed to read rules intelligently. It should not be allowed to replace the source simply by sounding confident.

The source boundary protects meaning from drift. The next boundary decides when the machine should stop resolving and ask a person to judge.

Human Judgment Should Resolve What Machines Cannot

Many human-in-the-loop systems are designed around fear. The agent reaches an uncertain state, stops, and asks the user to carry the missing machinery.

“Please provide the campaign ID.”

“Please confirm the advertiser account.”

“Please tell me which API endpoint to use.”

These questions may look safe. They often reveal that the system has no reliable way to resolve its own operational world.

Humans are valuable at a different boundary.

Ask a person when:

several verified candidates remain plausible;
a rule contains a genuine business judgment;
two approved sources conflict;
an exception requires an accountable owner;
an action has material cost, risk, or irreversibility;
the system cannot obtain sufficient evidence safely.

Do not ask a person to prove a machine-verifiable relationship. A user choosing “the second campaign” expresses intent. The platform must still prove that the campaign belongs to the active account and that the user may access it.

After clarification, the workflow returns to resolution. It does not jump to execution.

This placement makes the human loop feel collaborative. The agent handles discovery and evidence. The person supplies judgment where judgment is the scarce input.

Human judgment can resolve an ambiguous choice. It still cannot make different advertising platforms share the same operating structure.

Shared Roles Must Preserve Platform Reality

Marketing teams want one agent to work across Google Ads, DV360, The Trade Desk, Meta, Amazon, retail media, CRM, analytics, and whatever arrives next.

The obvious response is a universal structure. Account contains campaign. Campaign contains ad group. Ad group contains ad. Everything becomes the same four boxes.

The boxes break quickly.

DV360 has partners, advertisers, campaigns, insertion orders, and line items. The Trade Desk has its own hierarchy and operational assumptions. Paid social organises delivery differently. Retail media mixes product, merchant, audience, placement, and commerce data. A CRM lifecycle programme may have no useful equivalent to an ad group at all.

A better design separates the shared business role from the platform identity used for live work.

A DV360 line item and a TTD ad group may both play the business role of a “delivery unit.” That shared role helps the agent reason: both can carry targeting, bids, pacing, or inventory controls. Each object keeps the type and ID assigned by its own platform. A register of available operations decides what the agent can actually do with each one.

Shared business role
delivery unit
        ↓                         ↓
dv360.line_item              ttd.ad_group
        ↓                         ↓
DV360 operations             TTD operations

The shared role allows the agent to reason across platforms. The platform’s own object type prevents that generalisation from becoming a false promise.

Unknown types should remain visible. The agent can explain that it found a new kind of platform object or an unavailable operation. It cannot use that object for live work until a reviewed connector establishes what the object means and what operations are safe.

This is how an architecture grows without pretending the future already fits.

These three boundaries keep each fact, decision, and action in its proper place. They still do not guarantee that the complete workflow behaves correctly when the parts interact.

When Correct Components Produce the Wrong System

Component tests create comfort. The campaign lookup returns the expected data. Account access controls keep reads inside the selected client. Tool safety routes work through an approved connector. The review control rejects unapproved evidence plans. Every test passes.

Then two controls alter the same tool request.

One adds the correct client account. Another routes the request through the approved platform tool. Each change is sensible in isolation. Their combination becomes order-dependent. One may discard the other’s work. The later review control may fail to recognise the original request. The system now has a path that no component owner intended.

This pattern appears everywhere in agentic systems:

two safe policies create a deadlock that prevents the agent from gathering the evidence needed to proceed safely;
a retry in the harness combines with a retry inside the tool and multiplies cost or writes;
a clarification result survives longer than the account permission that made it valid;
a summary omits failed pages and presents a partial review as complete;
a generic cross-platform type erases the platform distinction needed for a correct action;
model-generated findings enter memory and return later as verified facts;
every layer blocks risk, while legitimate work becomes so painful that users bypass the agent.

The unit of design has to widen.

Element correctness asks whether each component works. Interaction correctness asks whether the connections preserve identity, permission, state, and evidence as information moves through the system. Whole-system correctness asks whether the complete workflow achieves the real outcome under ambiguity, failure, interruption, and change.

Safety is a system property. So is usability.

Correct interaction is still not enough if the system learns from the wrong account of success.

Feedback Must Return to Reality

Marketing has always had feedback loops. Most stop too early.

The platform reports impressions, clicks, attributed conversions, and perhaps revenue. The agent learns that one campaign “won.” Budget moves. The loop closes around the platform’s own account of success.

Agent-mediated marketing makes this more dangerous because the system can move faster. A fluent explanation can turn a proxy into a decision before anyone asks what happened after the click.

A useful operational world connects platform evidence to independent outcomes:

Exposure
  → selection
  → site or app event
  → order or lead
  → fulfilment
  → margin
  → return, retention, or reuse

The events may disagree. A browser event can be blocked. A server event may arrive later. A CRM record may enrich an identifier. An order may be cancelled. A conversion may be duplicated across browser and server paths. The reconciliation logic should preserve valid enrichment, distinguish conflicts, and retain the source of each claim.

Closing that loop requires four connected views: what the customer is trying to complete, who owns each signal, how platform events reconcile with independent outcomes, and whether the agent influenced retrieval, recommendation, selection, transaction, completion, or reuse. Our Who Owns the Pixel? research develops that measurement problem; the AI Skills Guide provides practical task-mapping, signal-ownership, reconciliation, and Share-of-Choice tools.

Feedback also needs a clear source label. A user correction can improve interaction memory. An evaluation score can reveal a weak workflow. A model reflection can propose a new skill. None of these should silently become platform identity, client requirements, or permission.

Learning that forgets where its evidence came from is another form of forgetting.

How to Build the First Version

The phrase “marketing ontology” invites an enterprise programme. Resist it.

Begin with one consequential workflow.

A campaign setup review is a good example because it touches language, knowledge, live platform settings, identity, evidence, and human judgment without requiring immediate changes. A campaign experiment or creative approval flow can work for the same reason.

1. Name the real outcome

“Automate campaign review” is a system activity. The outcome might be:

Help a campaign manager identify meaningful setup gaps against the current approved client requirements, with enough evidence to correct them confidently before launch.

This definition exposes what the system must preserve: the correct campaign, current requirements, live evidence, the seriousness of each gap, coverage, and a usable path to correction.

2. Model only the required objects

Start with a campaign reference, confirmed campaign, requirements source, individual requirement, evidence need, observation, review plan, finding, clarification, and proposed change.

Do not model the whole agency.

3. Decide which source can prove each claim

For every important statement, ask who may propose it, which source can verify it, who can approve its use, how current it must be, and whether it can permit a live action.

The model may propose a campaign candidate. The advertising platform confirms its identity. The control software approves the plan for execution. The requirements library confirms that the document belongs to the selected client. The user approves a change. The platform reports what happened afterwards.

4. Offer meaningful operations

Give the agent meaningful operations such as find campaign, inspect targeting, retrieve frequency evidence, preview budget change, and apply approved change.

Keep command syntax, API pagination, credentials, and platform-specific mechanics behind connectors. The model chooses meaningful operations. The control software checks their limits.

5. Give uncertainty a clear next step

Represent ambiguous, unsupported, incomplete, outdated, contradictory, and unavailable states. Give the agent a recovery path for each.

An unavailable operation should produce a clear explanation. It should not disappear from the final answer. Incomplete search results should trigger narrowing. An outdated requirement should identify the person who can resolve it.

6. Trace full scenarios

Test the ordinary case and the cases that expose the architecture:

one complete verified match;
two campaigns with similar names;
a matching campaign in another account;
an outdated policy document;
incomplete advertising-platform results;
an operation that supports TTD but not DV360;
cancellation during evidence retrieval;
a proposed correction after the campaign changed;
an approved write whose acknowledgement was lost;
a new kind of object introduced by an advertising platform.

7. Evaluate the composed system

Measure more than answer quality:

wrong-account and wrong-object rate;
automatic resolution rate;
unnecessary clarification rate;
incomplete evidence presented as complete;
unsupported-state transparency;
time to a useful finding;
policy and evidence freshness;
approval replay attempts;
post-change reconciliation success;
business-outcome improvement.

A system can fail by permitting bad work. It can also fail by making good work impossible.

The first version is therefore a shared design problem. Marketers define the decisions, evidence, and consequences that matter. Engineers turn those distinctions into durable identities, operations, controls, and records.

How Teams Divide the Work

What Marketers Should Define

Marketers do not need to become ontology engineers. They do need to make the operating world legible.

Start with decisions.

Which decisions recur every week? Which objects do those decisions affect? What evidence changes the decision? Which source owns each fact? Where does judgment enter? What would make the decision unsafe, incomplete, or misleading?

For a campaign review, define:

the difference between inspection, review, audit, recommendation, and execution;
the client policy sources that can govern a live check;
the meaning of complete coverage;
the exceptions that require a person;
the business consequence of each material gap;
the evidence that would change the recommendation;
the point where a proposed correction needs approval.

For creative work, define the brand objects and relationships that matter: approved claims, markets, rights, cultural contexts, past work, product truths, creators, formats, and evaluation criteria. Our Creative Operating System reached the same conclusion from another direction. Generation becomes infrastructure. The advantage moves into memory, judgment, coordination, and feedback.

The ontology—the working model of the business—begins when a team stops treating those elements as scattered documents and starts treating them as a connected account of how decisions are made.

What Engineers Should Build

The engineering brief is smaller than “build a digital twin of marketing” and stricter than “connect the model to every API.”

Build:

structured references that preserve the user’s language without pretending it is a verified identity;
platform-backed lookup that confirms the client, account, platform object type, platform-issued ID, and where the object belongs;
shared business roles that support cross-platform reasoning without erasing platform differences;
descriptions of each available operation, including supported objects, inputs, outputs, risks, access, and limits;
interpretations of requirements linked to the exact source passage and the evidence needed to test them;
validated plans that bind confirmed objects, requirements, available operations, and limits;
explicit workflow stages for clarification, validation, execution, cancellation, amendment, and completion;
limited human decisions followed by a fresh check of identity, access, and current state;
effect previews, exact approvals, duplicate protection, receipts, and reconciliation;
audit storage that retains full evidence safely;
operational monitoring that exposes state and failure without leaking client requirements, platform IDs, or sensitive data;
system-level evaluations that compose real policies, retries, tools, and versions.

Keep one trusted source for each important claim. Preserve identity across saved plans, restarts, and retries. Treat a plan amendment that changes the target as a new plan. Bind approval to the exact object, effect, budget, version, and expiry.

Most of this work looks less glamorous than the agent demo. It is the reason the demo can become a product.

The implementation can vary. The discipline does not require a particular vendor.

The Palantir Lesson Without the Palantir Dependency

“The Palantir way” can sound like a procurement recommendation. It is more useful as a design discipline.

Palantir’s approach contributes several durable ideas:

model real organisational objects rather than exposing raw storage shapes;
represent relationships explicitly;
place actions beside the objects they change;
connect logic, security, and operational workflows;
make the same model usable by people, applications, and agents;
close the loop between decisions and the systems where consequences appear.

Foundry may be the right implementation when an organisation already uses Palantir, needs its governance model, and wants to build through the Ontology SDK or Ontology MCP. Palantir’s documentation shows that these interfaces can make business objects, functions, queries, and actions available to applications while preserving the existing access rules.

Many marketing teams can apply the architecture with existing systems.

The operational model may live across shared data contracts, a register of available operations, access and approval rules, platform connectors, governed documents, event records, and the agent’s control layer. Some objects may be stored in a graph. Others may remain in databases, documents, or advertising-platform APIs. The conceptual model should follow the business. Storage can follow the workload.

Buying ontology software before understanding the decisions simply gives the confusion a formal structure.

The World Is the Product

The next generation of models will understand more of the user’s language. They will plan better. They will need fewer instructions. They will recover from weak tool responses with more imagination.

This strengthens the case for a good operational world.

A smarter agent can navigate richer objects and operations. It can interpret fuzzy rules with more sensitivity. It can ask fewer questions and select better evidence. It can explain trade-offs in language a marketer can use.

Its intelligence still needs somewhere to land.

A campaign must remain the same campaign across a conversation, a retry, an approval, and an API call. A client requirement must retain its source while the model interprets its intention. Evidence from an advertising platform must retain what it covered and when it was collected. A human decision must resolve the question that was actually asked. An approved effect must become an observed result in the real system.

Prompts shape behaviour for a moment.

The world around the agent determines whether that behaviour can become dependable work.

Reference Reading

Palantir Ontology

Ontology overview - Palantir’s operational-layer framing and its semantic and kinetic elements.
Ontology core concepts - object types, properties, links, actions, functions, roles, and interfaces.
The Ontology system - the integration of data, logic, action, and security.
Ontology permissions - resource, object, datasource, link, and action permission boundaries.
Developer toolchain and OSDK - programmatic access to ontology objects, actions, functions, and agent-oriented tooling.
Ontology MCP authentication and authorization - OAuth grants, application scopes, and underlying object permissions for agent access.

Performics Labs Research

The Agent Architect’s Playbook - building reusable AI skills for marketing and ad tech.
The Anatomy of a Marketing Agent - models, memory, skills, tools, roles, and orchestration.
The Muscles of the Machine - how tools, MCP, and CLI let agents do real work.
The Agentic Commerce Readiness Stack - identity, validation, receipts, and controlled execution.
Who Owns the Pixel? - task-led advertising, signal ownership, independent measurement, and agency value.
The Anti-Slop Marketing Stack - brand memory, judgment, evaluation, and distinctiveness.
The Creative Operating System - marketing creativity as an organisational system.

Practical Companion

AI Skills Guide - open skills, agents, tools, plugins, schemas, and reference implementations for marketing, ad tech, agent operations, and security.
AI Skills Guide source repository - manifests, examples, tests, installation paths, and contribution workflows.