Agent Control Plane: LLM Prompting & Agent Architecture

---

---

 

---

Technical Deep-Dive

LLM 프롬프팅 & 에이전트 아키텍처
완전 정리

싱글턴 · 컨텍스트 · 서브에이전트 · 스킬에이전트 · 오케스트레이터 · Ontology Layer — Palantir AIP 구조 참조

Prompting Agent Architecture Ontology LangGraph / MCP

전체 아키텍처 구조도

Palantir AIP — Ontology-Centered Architecture

AI Products Layer

Prebuilt AI Products  /  Custom AI Products  →  사용자가 접하는 최종 제품

⇅

★ Ontology Layer

Object 정의 (고객·주문·설비·직원…)  ·  Relation (소유·연결·의존…)  ·  Action (분석·승인·알림…)
→ 모든 에이전트가 공유하는 "세계 모델"

⇅

Data Services

RAG · Vector DB
External DB · API
Memory

AI Services

Sub-Agent
Skill Agent
LLM 추론 · Embedding

Workflow Services

Orchestrator
Pipeline · Routing
알림 발송

⇅

Security & Governance Layer

접근 제어 · 감사 로그 · 정책 적용 · 권한 관리 → Ontology Action 범위 검증

⇅

Software Delivery Layer

배포 · 버전 관리 · 인프라 · 모니터링

핵심 관점: 오케스트레이터는 Ontology Layer를 기준으로 요청을 해석하고 라우팅한다. 서브에이전트는 Object·Relation을 참조해 사고하고, 스킬에이전트는 Action 정의에 따라 실행한다.

---

01

Part 1

싱글턴 프롬프팅 vs 컨텍스트 프롬프팅

개요

프롬프팅은 LLM 출력 품질을 결정하는 핵심 요소이며, 사용 방식에 따라 크게 두 가지 접근으로 나뉜다.

항목	싱글턴 프롬프팅	컨텍스트 프롬프팅
방식	하나의 독립된 입력으로 완결된 응답 생성	이전 대화·상태·정보를 포함해 누적된 맥락 활용
상태	Stateless (무상태)	Stateful-like (상태 유지)
재현성	높음	낮음 / 유연성 높음
Ontology 활용	프롬프트 내 명시적 정의	공유 컨텍스트로 지속 참조

싱글턴 프롬프팅 (Single-Turn Prompting)

하나의 프롬프트 안에 필요한 모든 정보를 포함하여, 모델이 단일 요청만으로 결과를 생성하도록 하는 방식. 입력과 출력 관계가 1:1이며 이전 대화나 상태를 고려하지 않는다.

✓ 장점

• ›명확성: 프롬프트 자체에 모든 조건 포함
• ›재현성: 동일 입력 → 동일 출력
• ›디버깅 용이: 문제 원인 즉시 추적
• ›API 단발성 요청에 효율적

✗ 단점

• ›긴 입력 필요 (모든 정보 포함)
• ›복잡한 작업에서 비효율적
• ›상태 유지 불가

실무형 프롬프트 템플릿

prompt template

[Role]
너는 B2B SaaS 분석가다.

[Task]
다음 제품 소개서를 읽고 핵심 가치제안을 정리하라.

[Constraints]
- 5개 bullet 이내
- 마케팅 문구보다 실제 기능 중심
- 추정은 명시적으로 표시

[Output Format]
{
  "product_name": "",
  "target_customer": "",
  "core_value_props": []
}

[Input]
...

핵심 구성: Role + Task + Constraints + Output Format — "한 번에 끝낸다"

컨텍스트 프롬프팅 (Contextual Prompting)

이전 대화, 시스템 지시문, 외부 정보 등을 포함하여 맥락(context)을 누적하면서 응답을 생성하는 방식. 사실상 상태 기반 추론(stateful reasoning)이다.

실질적으로 포함되는 컨텍스트

• ›시스템 프롬프트
• ›최근 대화 히스토리
• ›사용자 선호 / 개인화 정보
• ›Ontology: 객체·관계·허용 행동

• ›도구 실행 결과
• ›검색 결과 / 중간 초안
• ›메모리에서 불러온 정보
• ›워크플로 상태값

실무에서는 컨텍스트를 무조건 쌓지 않고, 선별적으로 압축 / 요약 / 리셋한다. (Context Pruning)

핵심 비교

항목	싱글턴	컨텍스트
구조	단일 요청	다중 턴
상태	없음 (Stateless)	있음 (Context-aware)
재현성	높음	낮음
복잡도 대응	낮음	높음
토큰 사용	효율적	누적됨
Ontology	프롬프트 내 명시	공유 컨텍스트로 지속 참조
대표 용도	단순 작업 / 자동화	대화형 / 복잡 작업

---

02

Part 2

에이전트 아키텍처 개념

Ontology Layer

Ontology Layer는 에이전트가 세계를 이해하는 공통 언어다. 단순한 데이터 스키마가 아니라, 객체 간 관계와 허용 행동까지 정의한다.

ontology definition

Object:   고객, 주문, 제품, 설비, 직원
Relation: 고객 → 주문 (생성)
          주문 → 제품 (포함)
          설비 → 담당직원 (배정)
Action:   분석 가능, 승인 가능, 알림 발송 가능
          # 수정/삭제는 허용 범위 외

Ontology 없을 때

• ›각 에이전트가 "고객"을 다르게 해석
• ›데이터 구조 불일치
• ›허용되지 않은 행동 임의 시도

Ontology 있을 때

• ›모든 에이전트가 동일한 객체 정의 공유
• ›인터페이스 자동 정합
• ›Governance 자동 적용

서브에이전트는 Ontology의 Object·Relation을 기반으로 사고하고, 스킬에이전트는 Ontology의 Action 정의에 따라 실행한다.

서브에이전트 (Sub-Agent)

서브에이전트는 복잡한 문제를 분해하고 담당 영역별로 처리하는 역할을 가진 에이전트다.

"생각을 나눈다" — Task Decomposition. 역할 경계를 좁게 설정할수록 품질이 올라간다.

대표 패턴

A

Planner / Executor / Reviewer

Planner해야 할 일을 계획
Executor계획에 따라 내용 생성
Reviewer오류·누락·모순 점검

B

Researcher / Synthesizer / Critic

Researcher자료 수집
Synthesizer통합 서술
Critic근거 부족·과장 지적

C

Specialist Decomposition

Tech기술 관점 분석
Biz비즈니스 관점
Risk리스크 검토

D

Tree-of-Thought 확장

Branch AReasoning 경로 1
Branch BReasoning 경로 2
Merge최적 경로 선택

스킬 에이전트 (Skill Agent)

스킬 에이전트는 특정 기능(툴·API·계산 등)을 수행하는 실행 단위 에이전트다.

"행동을 수행한다" — Action Execution. Ontology Action 정의 범위 내에서만 동작 → Governance 자동 적용.

스킬 유형	AIP 레이어	예시
Search	Data Services	웹 검색 / RAG / Vector DB 조회
Code Execution	AI Services	Python / SQL 실행, 코드 테스트
API Call	Data Services	CRM 조회, 캘린더, 이메일, 결제
Memory Access	Data Services	단기/장기 메모리 저장·조회
Pipeline Trigger	Workflow Services	자동화 파이프라인 실행
Notification	Workflow Services	알림 발송, 이벤트 트리거

항목	서브에이전트	스킬에이전트
본질	역할 기반 추론 단위	기능 기반 실행 단위
초점	Reasoning (사고)	Action (행동)
Ontology 활용	Object·Relation 참조해 분해	Action 정의 참조해 실행
실패 유형	논리 비약, 누락	호출 실패, 포맷 오류
AIP 레이어	AI Services	Data / AI / Workflow Services

---

03

Part 3

실제 설계 / 구현 관점

구현 패턴

Pattern 4 — Ontology 포함 풀 구조

system flow

User Input
→ Context Loader
→ Ontology Layer  (Object / Relation / Action 식별)
→ Orchestrator
     ├→ Sub-Agent A  (AI Services)
     │      └→ Skill: Data Services  (RAG, DB)
     ├→ Sub-Agent B  (AI Services)
     │      └→ Skill: AI Services   (추론, 분류)
     └→ Sub-Agent C  (AI Services)
            └→ Skill: Workflow Services  (파이프라인, 알림)
→ Security & Governance Layer  (Action 허용 여부 확인)
→ Memory Update
→ Final Answer

구현 의사코드

python

def handle_user_request(user_input, context, ontology):
    # Ontology에서 관련 Object / Action 식별
    onto_context = ontology.resolve(user_input)
    route = classify_request(user_input, context, onto_context)

    if route.intent == "direct_answer":
        return single_prompt_answer(user_input, context, onto_context)

    plan = make_plan(user_input, context, onto_context)
    results = {}

    for step in plan.steps:
        # Governance: Action 허용 여부 확인
        if not ontology.is_action_allowed(step.required_action):
            raise GovernanceError(f"Action {step.required_action} not permitted")

        if step.required_skill:
            results[step.step_id] = call_skill(step.required_skill, step)
        else:
            results[step.step_id] = run_subagent(step, results, context, onto_context)

    draft  = synthesize_results(results, context, onto_context)
    review = review_draft(draft, context, onto_context)
    return  revise_draft(draft, review)

---

04

Part 4

설계 원칙 / 실패 패턴 / 결론

자주 생기는 실패 패턴

역할 경계 모호

서브에이전트 중복/충돌

각 에이전트 책임 범위를 좁혀라. 입/출력 명시.

툴 호출 기준 불명확

모델이 추정으로 답함

최신성/정확성 조건 명시, 특정 유형 무조건 툴 사용

컨텍스트 과적재

이전 내용 무한 누적 → 성능 저하

요약 컨텍스트, 필요한 상태만 유지

형식적 검토

리뷰 에이전트가 "좋습니다"만 반복

검토 기준 구체화, 수정 제안까지 요구

Ontology 없이 운용

에이전트마다 객체/행동 다르게 해석

Ontology Layer 분리 설계 필수

허용되지 않은 Action

Governance 미적용

Ontology Action 범위 검증 단계 추가

좋은 설계 원칙

• ›단순하게 시작 — direct_answer / research / review 3가지로. Ontology도 핵심 Object 3~5개부터.
• ›출력 구조화 — 자유서술보다 JSON schema 고정이 안정적.
• ›검증은 별도 단계 — 생성과 검증을 같은 단계에 넣으면 누락이 많다.
• ›툴은 필요한 순간에만 — Ontology Action 정의를 기준으로 판단.
• ›Ontology는 독립 레이어로 — 모든 에이전트가 동일하게 참조하는 단일 소스.
• ›최종 응답은 사용자 언어로 — 내부 구조화와 무관하게 사용자 관점으로 재구성.

최종 종합 정리

요소	핵심 역할	AIP 레이어	한 줄 요약
싱글턴 프롬프팅	독립적 단일 호출	AI Services 내부	한 번에 정확하게 끝내는 방식
컨텍스트 프롬프팅	누적 상태 기반 연속 처리	Ontology + AI Services	대화를 통해 점진적으로 완성
Ontology Layer	에이전트 간 공통 세계 모델	독립 레이어	모든 에이전트가 같은 언어로 세계를 이해
서브에이전트	역할별 사고 분해	AI Services	문제를 나눈다 — 추론 단위
스킬 에이전트	검색·계산·API 등 실행	Data / AI / Workflow	행동을 수행한다 — 실행 단위
오케스트레이터	전체 흐름 제어 및 통합	AI Services + Ontology	전체를 조율한다 — 제어층
Security & Governance	정책 적용 / 감사	독립 레이어	허용된 범위 안에서만 동작하게 보장

결론

좋은 LLM 시스템은 "프롬프트를 잘 쓰는 시스템"이 아니라,
Ontology로 세계를 정의하고, 문제를 올바르게 분해하고,
필요한 도구를 적절히 호출하고, 결과를 검증해서 다시 조립하는 시스템이다.

Singleton · Contextual · Ontology · Sub-Agent · Skill Agent · Orchestrator

---

+

실제 구현 사례

agent-control-plane

위에서 정리한 개념들을 직접 구현한 오픈소스 레포지토리

calicorone / agent-control-plane TypeScript

SideSeat(밋업 연결 앱)의 AI 에이전트 워크플로를 위한 Control Plane 구현체다. 에이전트가 데이터베이스에 직접 접근하지 않고, 반드시 거버넌스가 적용된 Ontology Layer를 통해서만 동작하도록 강제한다.

이 레포는 Palantir AIP에서 말하는 "에이전트가 Ontology를 통해서만 Action을 수행한다"는 패턴을 직접 구현한 형태다. 위의 이론을 실제 코드로 어떻게 옮기는지 볼 수 있다.

시스템 컨텍스트 블록도

agent-control-plane — System Context

Control Plane — this repo

CLI Runner

src/index.ts
args 파싱 → 에이전트 실행

Agent Loop

src/runner.ts
Think → Act → Observe

Tool Registry

src/registry.ts
허용된 툴만 등록

Roles + Guardrails

roles.ts / guardrails.ts
ops · backend · support

Agent Platform

backend/src/server.ts
UI + REST API

Pipeline Engine

pipeline-engine.ts
DAG 실행 (Drawflow)

HTTP + JWT  ↓↑  (WORKER_BASE_URL만 호출 — DB 직접 접근 불가)

SideSeat Product Repo (별도)

Worker API

Cloudflare Worker
/v1/* endpoints

React App

SideSeat UI
밋업 연결 앱

Supabase

Postgres + Auth
RLS 적용

에이전트 실행 루프 (Think → Act → Observe)

src/runner.ts — execution flow

Operator  →  CLI / runner  →  Anthropic or Ollama  →  SideSeat Worker

1. task + agent id + llm mode 입력
2. resolveRoleConfig → 허용된 툴 서브셋 결정
   loop (Max steps):
     Think  → LLM에 messages + tool defs 전송
     Act    → tool call 발생 시:
              allowlist 확인 + Zod validate
              → Worker API HTTP 호출
     Observe→ tool result를 context에 append
              → 다음 Think 단계로
     (최종 text 응답 시 loop 탈출 → stdout)

5-Layer 에이전트 스캐폴딩

모든 에이전트는 동일한 5개 레이어 스택으로 구성된다.

01

LLM

Language model — 로컬(Ollama) 또는 클라우드(Anthropic) 선택 가능

02

Agent Loop

Think → Act → Observe — 태스크가 resolve될 때까지 반복

03

Tool Use

allowlisted registry에 등록된 Worker API 툴만 호출 가능

04

Memory & Orchestration

대화 컨텍스트 유지, 파이프라인 시퀀싱 (DAG)

05

Guardrails / Eval

auth 확인, 출력 검증, 입력 필터링 — Security & Governance 적용

Ontology Layer 구현 (SideSeat 도메인)

에이전트는 raw SQL을 직접 쓰지 않는다. 모든 mutation은 Action을 통해서만 실행되며, Worker가 검증 및 감사 로그를 기록한다.

개념	역할	SideSeat 예시
Object Type	타입 스키마 정의	Meetup, Space, User, RSVP
Link Type	방향성 있는 관계 정의	Meetup → atPlace → Space
Action	거버넌스 적용 mutation	CreateMeetup (host role 필요, 감사됨)
Function	읽기 전용 쿼리 / 집계	getMeetupsBySpace, getRSVPCount
Policy	mutation 전 RLS 적용	host만 자신의 Meetup 수정 가능

에이전트 Role 설계

각 에이전트는 Role을 가지며, Role이 허용하는 toolIds만 호출할 수 있다. DB 직접 접근은 어떤 Role도 불가능하다.

ops

시스템 헬스 모니터링

health · status tools

backend

데이터 동기화 · 유지보수

CRUD tools · migrations

support

사용자 대면 Q&A

read-only tools

레포지토리 구조

directory structure

agent-control-plane/
├── src/                   # 코어: CLI, loop, registry, roles, guardrails
│   ├── index.ts           # CLI 진입점
│   ├── runner.ts          # Think → Act → Observe 루프
│   ├── registry.ts        # 툴 소스오브트루스 (Zod schema)
│   ├── roles.ts           # ops / backend / support 정의
│   └── guardrails.ts      # allowlist 강제 + 감사 로그
├── backend/               # 플랫폼 서버: JSON API + React UI 서빙
│   └── src/routes/        # agents / pipelines / tools / system
├── platform-web/          # React UI (Vite + TypeScript)
│   └── src/pages/studio/  # Ontology & workflow canvas (Drawflow)
├── data/                  # 런타임 생성 — git-ignored
│   ├── agents/            # 커스텀 에이전트 JSON
│   └── pipelines/         # 파이프라인 DAG JSON
├── docs/                  # 아키텍처, 온톨로지, 프롬프팅 가이드
├── Dockerfile
└── docker-compose.yml     # ollama + agents + agent-platform

이론 → 구현 매핑

이론 개념	agent-control-plane 구현체	파일
Ontology Layer	Object/Link/Action/Policy 스키마	docs/SideSeat-Ontology-Agents.md
Orchestrator	CLI Runner + resolveRoleConfig	src/index.ts, src/resolve-agent.ts
Sub-Agent	Think → Act → Observe 루프	src/runner.ts
Skill Agent	Tool Registry (Zod 검증 포함)	src/registry.ts
Security & Governance	Guardrails + Role allowlist	src/guardrails.ts, src/roles.ts
Workflow Services	Pipeline Engine (DAG, Drawflow)	src/pipeline-engine.ts
AI Products Layer	Agent Platform UI (React + Vite)	platform-web/, backend/

---

★

Reference Architecture

Palantir AIP — 공식 아키텍처 분석

이론과 구현을 연결하는 산업 레퍼런스

Palantir AIP 공식 아키텍처 다이어그램을 보면 이 글에서 정리한 개념들이 어떻게 실제 엔터프라이즈 플랫폼에서 구현되는지 확인할 수 있다. 12개 컴포넌트가 번호로 매핑되며, 전부 Ontology를 중심으로 연결된다.

핵심 관찰: 다이어그램에서 나머지 11개 컴포넌트가 전부 Ontology(4, 5번)를 향해 연결되거나 Ontology에서 나온다. Ontology는 단순한 데이터 스키마가 아니라 "사람과 에이전트 모두가 읽을 수 있는 운영 언어"다.

Ontology Core — 3개 엔진

Semantic

의미 기반 데이터 모델
Object · Link · Action
인간+AI 공통 언어

Kinetic

실행 엔진
수십만 Action 오케스트레이션
수십억 Object 쿼리

Dynamic

실시간 피드백 학습
지속적 Ontology 갱신
Human+AI Decision Model

12개 컴포넌트 전체 구조

Palantir AIP Architecture — Component Map

Agents & Automations (출력 레이어)

Operational Teams

Developer Teams

Analyst Teams

Governance Teams

⇅

③ Context Engineering

Contextual Data

→

Contextual Logic

→

Systems of Action

④⑤ ONTOLOGY ★

Semantic

Kinetic

Dynamic

Data

Logic

Actions

OSDK

Media & Vector · Multimodal Compute

⑥ Security & Governance

Role-based Controls

Marking-based Controls

Purpose-based Controls

Audit Logging

⇅

⑦ Agent Lifecycle

Agent Building
Orchestration
Evaluation Suites

⑧ Operational Automation

Scheduled
Event-driven
API-driven

⑨ Dev Environments

VS Code · JupyterLab
Platform SDK
Palantir MCP

② End-to-end Observability

Token tracking
Action audit
Chain trace

⑩ Human+AI Applications

No/low-code App Building
Object-oriented Analytics
Multimodal Governance

⑪ Package, Release, Deploy

Product Packaging
Release Channels
DevOps toolchain

⑫ Enterprise Automation

AI FDE · AIP Assist
Global Branching
Human-in-the-loop

⇅

① Secure LLM Integration, Hosting & Access

Moderation

PII Obfuscation
Content Detection
데이터 비보존 보장

Infrastructure

Smart Cache
Dynamic Retry
Rate Limiting

Model Catalog

Commercial (GPT, Gemini, Claude, Grok)
Open-Source (Llama)
BYOM · Custom

다이어그램에서 읽어야 할 핵심 포인트

INSIGHT 01 에이전트가 Ontology를 우회할 수 없는 구조적 이유

Security & Governance(⑥)가 Ontology(④⑤) 위에 올라가 있다. Role-based + Marking-based + Purpose-based Controls가 Ontology 레이어에서 적용되므로, 에이전트가 Ontology를 우회하면 거버넌스 자체가 무너진다. 이것이 agent-control-plane에서 guardrails.ts가 registry.ts의 allowlist를 강제하는 이유와 정확히 같은 논리다.

INSIGHT 02 Enterprise Automation(⑫) — 에이전트와 사람이 동일한 레일 위에서 동작

가장 흥미로운 부분이다. AI FDE, AIP Assist 같은 에이전트가 사람과 동일한 Global Branching 시스템 위에서 동작한다. 즉, 에이전트의 변경도 사람의 변경과 동일한 change management를 거친다. "에이전트가 자율적으로 동작한다"는 것이 "에이전트가 거버넌스 밖에 있다"는 의미가 아니다.

INSIGHT 03 Secure LLM Integration(①) — "데이터 비보존"이 인프라 레벨 보장

GPT, Gemini, Claude, Grok 등 상업 모델을 쓰더라도 Palantir 관리 인프라를 통해 라우팅되므로, 전송된 데이터가 써드파티 제공자에게 retain되거나 재학습에 사용되지 않는다. 이것이 엔터프라이즈가 퍼블릭 LLM API를 직접 호출하지 않고 AIP를 통하는 이유다.

AIP 공식 컴포넌트 × agent-control-plane 구현 대응

# AIP	AIP 컴포넌트	레포 구현	파일
①	Secure LLM Integration	Ollama(로컬) / Anthropic(클라우드) 선택	src/runner.ts, .env
②	End-to-end Observability	파이프라인 run 히스토리 (경량 구현)	src/run-history.ts
③	Context Engineering	툴 정의 + Zod 스키마 + 역할별 툴셋	src/registry.ts
④⑤	Ontology System ★	Object/Link/Action/Policy 스키마	docs/SideSeat-Ontology-Agents.md
⑥	Security & Governance	allowlist 강제 + audit log + role 정책	src/guardrails.ts, src/roles.ts
⑦	Agent Lifecycle	Think→Act→Observe 루프 + Platform Studio UI	src/runner.ts, platform-web/
⑧	Operational Automation	DAG 파이프라인 실행 (Drawflow 기반)	src/pipeline-engine.ts
⑨	Development Environments	Agent Platform UI + Docker 컨테이너	backend/, Dockerfile, docker-compose.yml
⑩⑪⑫	Human+AI Apps / Package / Enterprise Automation	미구현 (SideSeat product repo 영역)	— (별도 repo)

결론

좋은 LLM 시스템은 "프롬프트를 잘 쓰는 시스템"이 아니라,
Ontology로 세계를 정의하고, 문제를 올바르게 분해하고,
필요한 도구를 적절히 호출하고, 결과를 검증해서 다시 조립하는 시스템이다.

Singleton · Contextual · Ontology · Sub-Agent · Skill Agent · Orchestrator · Palantir AIP

 

---

Palantir

 

AIP architecture

As described in the overview of AIP, Foundry, and Apollo, AIP is Palantir’s platform for connecting generative AI into operational domains. While AIP and Foundry operate together as part of a shared service mesh, powered by Apollo and deployed within Rubix, this page provides a view of AIP's end-to-end architecture through an AI-centric lens. This includes capabilities for securely connecting to the full range of LLMs, continuously integrating context into the Ontology, building agents and automations, observing and evaluating the ongoing performance of deployed agents, and a full developer toolchain for managing AI-driven products.
The AIP architecture can be summarized into 12 general categories of capability:

1. Secure LLM integration & access: Enabling secure access to the full range of commercial LLMs (e.g., GPT, Gemini, Claude, Grok models) and open-source models (e.g., Llama), through Palantir-managed infrastructure that ensures that no transmitted data is retained by third-party providers, and no transmitted data is used for retraining by model providers. Enterprises can also integrate their existing models, whether existing model subscriptions, fine-tuned models, or domain-specific models.
2. End-to-end observability: Providing monitoring tools for every step of AI-driven workflows and agentic processes. This includes fine-grained monitoring for all data flows that feed the Ontology, logging for every action taken by human users or AI agents, and the ability to trace the cascade of chained executions in a workflow. This observability extends to token consumption and other aspects of resource usage.
3. Context engineering: Equipping developers with no-, low-, and pro-code tools for integrating the contextual data, logic, action that power the Ontology and all dependent workflows. All modalities of data integration (e.g., batch, streaming, real-time replication via CDC) can be leveraged through any runtime (e.g., Spark, Flink, DataFusion, Polars), while adhering to cohesive security, governance, provenance-tracking, and other essential guarantees.
4. The Ontology system: Activating context by integrating disparate data, logic, action, and security into a unified representation of enterprise decision-making. Read more about the Ontology.
   • The Ontology’s language models the "nouns" and "verbs" of operational processes into a legible form for both humans and agents.
   • The Ontology’s engine enables querying billions of objects, orchestrating tens-of-thousands of actions, and continuously incorporating feedback-based learning.
   • The Ontology’s toolchain empowers developers to build diverse and complex AI-powered applications, atop a common foundation.
5. Vector, compute, tool services: Providing the integrated vectorization services needed to produce and manage embeddings; an extensible compute framework that can leverage multi-node engines (e.g., Spark, Flink), efficient single-node engines (e.g., DuckDB, Polars), and any containerized “BYO” engine; and an integrated set of tool services that work with the Ontology system to function as an ever-evolving tool factory. The platform is designed to be modular and extensible with respect to models, compute engines, and interfaces.
6. Security & governance: Ensuring that every operation made by humans and agents abides by rigorous role-, marking-, and purpose-based controls. This requires a combination of infrastructure, platform, and enterprise security controls. These controls can be granularly configured and dynamically interrogated, and are cataloged in expressive audit logging. Governance capabilities extend uniformly across all operational, engineering, and developer activities performed within the platform interfaces as well as programmatically through the APIs/SDKs.
7. Agent lifecycle: Powering the interconnected building, orchestration, and evaluation processes for agents in production. Agents can be constructed using no-, low-, and pro-code workbenches. Durable orchestrations can be configured and managed through low-code interfaces like AIP Logic, or pro-code interfaces like Code Workspaces. The integrated evaluation framework (AIP Evals) operates seamlessly with the Ontology, enabling you to create test cases, debug and iterate on agent definitions, compare performance across different LLMs, examine the variance across executions, and more.
8. Operational automation: Facilitating the different modes of automation required within and across workflows. This includes scalable schedule-based automations, near real-time event-driven automations that process streaming data, and automations which are enmeshed with API-driven operations. Regardless of the modality, every automation can leverage the rich set of data, logic, and action primitives in the Ontology system, and a wide array of execution and notification configurations.
9. Development environments: Empowering developers to build agents and automations, how and where they want to. AIP provides integrated development environments (e.g., VS Code, JupyterLab), which provide seamless connectivity with Ontology-driven applications and integrated testing and evaluation frameworks. In equal measure, the Platform SDK and Ontology SDK, in conjunction with Palantir’s VS Code plug-in, bring the same core functionality to existing environments and developer toolchains. Additionally, Palantir MCP provides a secure interface for agentic development (analogous to what is possible in the platform with AI FDE).
10. Human + AI applications: Providing the full spectrum of AI-driven experiences; from object-oriented analytics, to real-time application building, to multimodal governance workflows, to the administration of core platform capabilities. Operational users, compliance teams, engineers, analysts, and other key personas have out-of-the-box applications specifically tailored for their workflows, as well as the ability to rapidly construct new Ontology-powered applications. In each case, the infusion of AI can be carefully controlled and transparently assessed, ensuring a smooth journey from augmentation to automation.
11. Package, release, deploy: Allowing developers to move beyond point analytics and applications to build fully featured AI products which leverage an integrated DevOps toolchain. End-to-end collections of data pipelines, Ontology definitions, automations, and prebuilt applications can be packaged, released, and deployed across heterogeneous target environments. Developers can specify allowances for "last-mile" customization, and downstream teams can securely receive updates as product definitions evolve, and as changes are validated and promoted across release channels.
12. Enterprise automation: Enabling builders, of all personas and backgrounds, to wield specialized AI agents (e.g., AI FDE, AIP Analyst) to construct data pipelines, write business logic, train models, build ontologies, produce analytics, and develop end-to-end applications. Critically, these agents operate atop the same foundation as human users, meaning that they abide by the same integrated change management capabilities (e.g., Global Branching), and can seamlessly weave human-in-the-loop workflows with entirely autonomous operations.