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

A marketing agent can understand a request and still fail at the work.

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

The request gives the agent a useful direction. It does not identify the advertising platform, account, or exact campaign. The requirements library may contain several plausible sources. The platform may not expose every setting. The agent can infer likely answers, but it cannot treat those inferences as verified identity, approved policy, or complete evidence.

Adding more instructions to the prompt will not settle those questions. The system needs a reliable way to connect the user’s words to real business objects, their sources, the operations available on them, and the evidence those operations return. Call that an operational model, or an ontology. Its purpose is practical: let the agent reason about the work while preserving what is known, what is inferred, and what remains uncertain.

That is the useful idea behind Palantir’s Ontology. The larger point is that marketing agents need a model of the business they work in, not only a model of the language they receive.

The gap between a request and a real campaign

The user said “summer prospecting campaign.” That phrase may help the agent find candidates. It does not uniquely identify one. A campaign name can be reused across years, accounts, and advertising platforms. The system needs to confirm the platform-issued ID and the account it belongs to before calling an API.

“Approved campaign requirements” also needs resolution. A document title does not prove that a source is current, applies to this client, or governs this channel. And “review” could mean retrieve a past audit, inspect the live setup, or recommend changes. The system needs to keep those tasks distinct.

This is the gap between an agent’s interpretation and the state of the business. Language models are useful for interpreting phrases, considering context, and proposing likely next steps. They cannot turn a likely campaign into a verified record, a document into approved policy, or a missing API field into evidence.

An operational model gives the system a place to preserve those differences. It connects:

business objects, such as a campaign, advertiser account, creative, requirement, or outcome;
relationships, such as a campaign belonging to an account or a creative being approved for a market;
sources that can establish identity, policy, and current state;
operations that can inspect or change an object;
permissions and conditions attached to those operations;
observations that show what happened after the system acted.

The model does not need to live in one database or product. It can span platform APIs, governed documents, data contracts, permissions, and workflow software. What matters is that the links remain usable and their origins remain visible.

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’s Ontology contributes

Palantir describes its Foundry Ontology as an operational layer connecting integrated data and models to their real-world counterparts. Its documentation distinguishes semantic elements, such as objects, properties, and links, from kinetic elements, such as actions and functions that enable controlled change. The overview also describes security as part of this model. Palantir’s Ontology overview and core concepts explain the product’s terminology.

That combination is more useful than a catalogue of tables. A campaign object can carry a stable identity and relationships to its account, delivery units, requirements, and evidence. An operation can inspect or update that campaign, with defined inputs, access rules, conditions, and a record of the result. The system can connect a decision to the object it affects.

Marketing has long organized data around impressions, clicks, costs, conversions, audiences, and creative assets. Those records matter, but an agent also needs to know what they represent and how they relate. A client rule is more than a document fragment. A budget recommendation is more than generated text. Each has a source, a target, limits, and possible consequences.

This is the distinction between describing the business and representing the work that may be done in it. Palantir offers one implementation of that idea. Teams can apply the same discipline with other systems and their existing data stores.

Give the agent a map before giving it a route

An agentic system has several parts, and each answers a different question:

Purpose          What outcome should this work serve?
Agent            What does the request mean, and what should happen next?
Harness          What state, context, limits, and workflow stage apply?
Skills           What procedure fits this kind of work?
Operational model  Which real objects, relationships, and operations are involved?
Trust and control  Which facts, sources, and actions are verified and permitted?
Execution        Which approved connector carries out the read or change?
Observation      What did the external system report, and what happened afterwards?

The Anatomy of a Marketing Agent follows the runtime handoffs. The operational model supplies what those handoffs refer to: the confirmed campaign and account, the applicable requirements, available operations, and returned evidence. The agent can propose candidates; connectors, governed sources, and policy checks establish the facts and authority the workflow relies on.

The model should have room to reason where judgment is useful. It can compare candidates, choose relevant evidence, select the next read operation, and explain a conflict. Some conditions must remain deterministic: access to one client’s data, exact object identity for a write, the approval required for a budget change, and whether an operation actually succeeded.

The roles need not be separate services, but their records must retain their meaning. A tool response does not prove complete coverage, a saved summary does not establish current state, and a skill does not grant permission. A person’s choice identifies their intended campaign; the system still verifies account ownership and access.

The pieces can also behave correctly alone and fail together. Suppose one control adds the confirmed client account to a tool request. A second control routes it through an approved connector by rebuilding that request. If the second drops the account field, its safe routing can undo the first control’s safe scoping. Reversing their order may produce a different result. Both component tests can pass while the effective request reaching the platform is wrong.

The system needs to preserve the request’s lineage: its original purpose, resolved target, transformations, and final account and operation. Interaction tests should check that the final request retains all required boundaries, whichever legitimate route produced it. A retry must also retain valid scope, and a summary must retain evidence of failed pages. Testing only the individual controls misses what they can overwrite or conceal.

Follow one campaign review from request to evidence

Start with the request: “Review the live setup of our summer prospecting campaign against the client’s approved campaign requirements.” A trustworthy workflow moves through a few explicit stages.

Interpret, then resolve identity

The model treats “summer prospecting” as a reference and proposes search clues. The platform connector searches within the user’s authorized account. It returns platform records with their object types, IDs, account relationships, and relevant status.

If one candidate matches the available clues and the search is complete, the agent can proceed. If two remain plausible, it asks the user to choose between those candidates. If the results are incomplete, it says so and narrows the search. The readable campaign name supports conversation; the platform-issued ID supports the API call.

Establish which requirements apply

The system finds the requirements source for the client and checks its version, approval status, scope, and effective date. The source says what the campaign should do. It does not prove what the live campaign does.

The advertising platform provides observations about current settings. It does not decide what the client intended. A previous audit may explain an earlier decision, but it cannot certify the current setup. Keeping these sources separate prevents one from silently standing in for another.

Turn each rule into an evidence question

Client requirements often contain contextual language. “Keep prospecting frequency appropriate for the audience and campaign objective” cannot always be tested by comparing one number with a fixed limit.

The model can interpret the sentence and suggest relevant evidence: frequency distribution, reach, recency, audience size, objective, creative rotation, or response by exposure count. The system keeps that interpretation linked to the exact source passage. It records what evidence would support or challenge the interpretation, then retrieves observations from the confirmed campaign.

Keep five records distinct as that rule moves through the workflow. This is a proposed internal record model, rather than a Palantir or advertising-platform schema:

Record	What it preserves for the frequency rule
Trusted source	Client, document, version, effective date, approval status, and exact passage containing the requirement
Interpretation	The agent’s reading that the rule aims to protect experience and avoid waste from repeated exposure
Evidence requirement	The observations needed to test that reading, such as frequency distribution, reach, recency, audience size, objective, and creative rotation
Observation	What the confirmed campaign’s platform operation returned, including time, fields, and missing or incomplete data
Finding	How those observations relate to the interpreted requirement, with evidence links, uncertainty, and coverage

These records can become stale independently. A policy revision can invalidate an interpretation even while the platform observation remains accurate. A campaign change can invalidate a finding even while the policy remains current. Keeping the records linked lets the system identify what needs to be reconsidered.

For each requirement, the finding should distinguish an observed match, an observed gap, not evaluated, and source unavailable. A missing field is not a pass or a failure. A successful API call does not by itself establish complete coverage. The model’s interpretation must not replace the source rule; a live setting must not become policy merely because it exists; and yesterday’s finding must not return from memory as a verified fact about today.

Report what the review can support

The final response should name the campaign and account it reviewed, identify the requirements source and version, say how much was covered, and separate findings from uncertainty. It should make clear whether the system only inspected the setup or also proposed or applied a change.

This is where fluency helps. The agent can explain the findings in plain language because the workflow has preserved the evidence beneath them. If the review is partial, it reports the limitation. If two approved sources conflict, it asks the appropriate owner. If the user asks for a change, the system starts a separate permission and approval check.

Keep inference, evidence, and permission separate

Three distinctions keep this workflow honest.

Inference is a proposal. The model can infer that a campaign name refers to a particular initiative, or that a broad requirement concerns user experience. It should be able to show the clues and remain open to correction.

Evidence is an observation from a source. A platform response can show a current setting, with a timestamp and scope. A requirements library can show an approved rule and its provenance. Neither source proves claims outside its remit.

Permission is authority to perform an operation. A user may be allowed to inspect a campaign but not change it. Approval for a specific budget update should bind to the confirmed object, proposed effect, limits, and time window. It should not become reusable permission for a different campaign or later plan.

Confidence in an inference cannot replace evidence or permission. A model can be very sure about which campaign the user means and still need the connector to verify the account. A user can want a change and still lack authority to approve it. A policy can permit a read while withholding a write.

Human review belongs where machine verification ends or where accountable judgment is required: competing verified candidates, conflicting policies, subjective requirements, consequential exceptions, or actions with material cost or risk. People should not need to supply IDs or API syntax that the system can reliably retrieve and validate.

Teams often want one agent to work across Google Ads, DV360, The Trade Desk, Meta, Amazon, retail media, CRM, and analytics. A universal platform hierarchy looks convenient: account, campaign, ad group, ad. The objects do not line up neatly enough to make that a safe assumption.

The system can define a shared business role such as “delivery unit” for objects that carry targeting, bidding, pacing, or delivery controls. Under that role, it preserves each platform’s own object type and identity:

Shared role: delivery unit
    DV360 line item  → DV360 operations and identity
    TTD ad group     → TTD operations and identity

The shared role helps the model reason across systems. The platform-specific type tells the connector which operations actually exist. Unknown objects remain unknown until someone establishes their meaning and safe operations. This lets the model grow as platforms change without pretending every new object fits the old hierarchy.

Close the loop with outcomes outside the platform

The platform may report impressions, clicks, and attributed conversions. Those measures do not always establish what happened to the customer or the business. A conversion can be duplicated across browser and server events. An order can later be cancelled or returned. A CRM record may enrich an identifier, but it may also arrive late.

An operational model can connect a sequence of evidence while preserving its source and status:

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

The system needs explicit reconciliation rules for late, missing, and conflicting events. It should record whether an agent influenced discovery, recommendation, selection, transaction, completion, or reuse, without treating every platform-attributed conversion as an independent outcome. Who Owns the Pixel? examines signal ownership and independent measurement; the AI Skills Guide includes practical tools for task mapping and signal reconciliation.

Feedback can improve a workflow, but its source still matters. A user correction may update interaction memory. An evaluation can reveal that a workflow is weak. A model reflection can propose a new skill. None should silently become client policy, verified platform identity, or permission.

Build the smallest useful world

“Marketing ontology” can sound like an enterprise data programme. Start with a decision that matters and the smallest set of objects needed to make it well.

For a campaign setup review, that may mean a campaign reference, confirmed platform campaign, account, requirements source, individual requirement, evidence need, observation, review finding, and any clarification or proposed change. Each object should answer a question in the workflow, rather than exist because the schema has room for it.

For each important claim, decide what can propose it, what source can verify it, who can approve its use, how current it must be, and whether it can authorize an action. Then describe operations in business terms such as find campaign, inspect targeting, or preview budget change. Keep API pagination, credentials, and platform syntax behind the connector. The model chooses meaningful operations; control software checks their target, inputs, access, and limits.

Evaluate at three levels, because each can reveal a different failure:

Level	Campaign-review question	Evidence to inspect
Component	Does lookup resolve the right object, and does requirement retrieval return the applicable source?	Wrong-account or wrong-object results, source freshness, coverage, and whether the system can resolve available IDs without user help
Interaction	Do routing, scoping, retries, review, and summarization preserve each other’s conditions?	Final request identity and permissions, retained evidence links, partial results labelled as partial, and approval invalidated when the proposal changes
Whole workflow	Does the user receive a useful, supported review and, where separately authorized, a verified change?	Unnecessary clarification, time to a useful finding, unsupported claims of completeness or transparency, approval reuse, and reconciliation with the platform after execution

Use similar campaign names, a match in another account, stale requirements, incomplete search results, unsupported operations, interruption, and lost acknowledgements to exercise those levels. Inspect what happened throughout the run, alongside the final answer. The broader agent builder playbook explains how to maintain an evaluation set; here the focus is whether the operational model preserves meaning and authority between components.

Usability belongs in that evaluation too. Two controls can each reject unsafe work yet together block the evidence read needed to complete a permitted review. Diagnose that conflict and provide an authorized route or a clear escalation. A system that constantly asks people to supply machine-retrievable facts, or blocks legitimate work without explanation, invites bypasses. Conversely, a fast review is not successful if it silently omits the hardest requirements. Any claim of business improvement needs separate outcome evidence beyond these workflow measures.

Marketers define the decisions, evidence, exceptions, and consequences that matter. Engineers encode durable identities, relationships, operations, controls, workflow states, and records. The work is shared because neither side can define the whole operating world alone.

A design discipline, not a vendor requirement

Palantir’s Ontology makes the operational-model idea explicit: connect real-world objects and their relationships to logic, actions, and security. Its architecture documentation describes that integration, while the developer toolchain and Ontology MCP authorization documentation describe ways to expose ontology capabilities while applying access controls.

Foundry may suit an organisation that already uses Palantir and needs its governance and development environment. Other teams can represent the same discipline across data contracts, platform connectors, governed documents, operation registries, approval rules, and workflow software. The business model should follow the decisions people need to make. Storage can follow the workload.

Buying ontology software before understanding those decisions only formalizes the confusion.

The model will improve at interpreting language and choosing useful steps. The agent will still need to know which campaign it found, where the requirement came from, what the evidence covered, what it was allowed to do, and what happened afterwards. Those relationships are the operational world that lets fluent reasoning become dependable work.

Reference reading

Palantir Ontology

Ontology overview - Palantir’s description of the operational layer and its semantic and kinetic elements.
Ontology core concepts - object types, properties, links, actions, functions, and interfaces.
Ontology system architecture - how the product connects data, logic, actions, and security.
Ontology permissions - permission boundaries for ontology resources and actions.
Developer toolchain and OSDK - programmatic access to ontology objects, actions, and functions.
Ontology MCP authentication and authorization - authentication scopes and underlying object permissions for agent access.

The Agent Architect’s Playbook - reusable skills for marketing and ad tech.
The Muscles of the Machine - how tools, MCP, and CLI connect agents to software.
The Agentic Commerce Readiness Stack - identity, validation, receipts, and controlled execution.
The Anti-Slop Marketing Stack - brand memory, judgment, evaluation, and distinctiveness.
AI Skills Guide - practical skills, agents, tools, and reference implementations for marketing and agent operations.

Publication history

Originally published by Performics Labs.