This blog has mostly covered Palantir Foundry and the Ontology so far. But after actually using AI agent tools like Claude Code, Codex, and similar recently, it became clear there’s a separate set of concepts that matter to anyone putting AI to work right now, even if they’ve never heard of an Ontology. This article kicks off a few posts covering exactly those concepts.
What Makes an AI Agent Different From a Chatbot
Ask a chatbot like ChatGPT a question, and the AI answers in text and stops there. Whatever happens next, a person has to do it.
An AI agent goes a step further. It creates files directly, runs code, checks the result, and moves on to the next step on its own. Tell it once, “analyze this log file and turn it into a chart,” and the agent reads the file, cleans up the data, writes the charting code, and runs it — all by itself.
Think of a chatbot as a support rep you call on the phone, and an agent as more like an employee who sits down and actually does the work.
Context Window — What the Agent Currently Remembers
When you type a prompt into an AI agent, it doesn’t go straight into the AI model. It first lands in a space called the Context Window, and everything sitting in that space gets fed to the model together.
This space holds things like:
- The prompt you just typed
- Files that define project rules (like AGENTS.md, covered later)
- The conversation so far
- The contents of files the agent has read
This space isn’t infinite. Once it fills up, the agent has to summarize or trim older content, and if important context gets lost in that process, the agent can suddenly start behaving oddly. This is also why an agent starts drifting away from your instructions little by little as its Context Window gets fuller.
Practical tip: the longer a task runs, the more worth being mindful of this space filling up. Clearing out unnecessary conversation or file content along the way keeps more room free, and the agent runs more reliably as a result.
Subagent — Why Splitting Work Beats Having One Agent Do Everything
Hand one AI agent an entire complex task, and everything — planning, implementation, verification — ends up mixed together inside that one agent’s Context Window. The more varied the information gets, the higher the odds of confusion and mistakes.
A Subagent is how you solve this. You split one large task into several independent agents, each focused only on its own piece.
Take drafting several pieces of marketing copy as an example.
- Hand it to a single agent: one agent has to simultaneously juggle “write a draft, check it against our brand tone, proofread it, and make sure it doesn’t overlap with competitor copy.”
- Split it into Subagents: a copywriter agent only writes the draft, a tone-review agent only checks it against the brand guide, and a proofreading agent only checks for typos. A lead agent gathers and finalizes all three results at the end.
Because each Subagent only holds the information it needs for its own role in its Context Window, there’s less room for confusion and the accuracy of the output goes up.
Skill — Saving a Repeated Instruction as a Single Command
Typing out the same long instruction every time is wasteful. A Skill saves a frequently-used prompt or work procedure as a single command.
Broadly, two things can become a Skill.
- A frequently-repeated prompt turned into a single command (e.g. turning a long instruction like “polish this document in our company’s tone” into one line,
/tone-check) - A bundled procedure for using a specific tool — editing files, running commands, web search — turned into a command (e.g. turning the whole process of reading and summarizing a PDF into
/pdf-summary)
Build up a good library of Skills, and you can run a task with a single command instead of re-explaining it every time you repeat it.
Watch out: a Skill often contains executable code. Installing a Skill from an unverified source as-is can carry a real security risk — favor officially vetted Skills whenever you can.
MCP — The Channel That Connects an Agent to Outside Tools
By default, an AI agent can only use what’s built into it. But to control a browser directly, or pull data from a specific company’s service, it needs to connect to an external program.
MCP (Model Context Protocol) is the common standard for that connection. An agent (the MCP Client) asks an outside tool (the MCP Server) to “do this task,” the MCP Server carries it out, and hands the result back.
Think of it like this: instead of learning every foreign language itself, the agent talks through a specialist interpreter (the MCP Server) whenever it needs to. Through that interpreter, the agent can get things done that it couldn’t do on its own.
Common real-world examples include an MCP that drives a web browser automatically, and an MCP that connects to a specific company’s database. OMCP (Ontology MCP), which this blog has covered before, works on the same principle — it’s the channel that lets an AI agent connect to Palantir Ontology data.
Wrapping Up
| Concept | One-line definition |
|---|---|
| Context Window | The space holding what the agent currently remembers and references |
| Subagent | A way to split a large task by role, across multiple agents |
| Skill | A frequently-used instruction or work procedure, saved as a single command |
| MCP | The common channel connecting an agent to outside tools and services |
These four are the basic vocabulary you’ll need to understand prompt/context engineering, harness engineering, and agentic engineering, all covered later in this series. The next article covers exactly how prompt engineering and context engineering differ.
AI Agent Series — Full Table of Contents
- (Part 0, before you start) Setting Up an AI Agent Practice Environment
- (1/5) What Is an AI Agent? — you are here
- (2/5) Prompt Engineering vs. Context Engineering
- (3/5) What Is Harness Engineering?
- (4/5) Agentic Engineering and the PH-AH Loop
- (5/5) Hands-On Practice With 4 AI Agent Concepts
Beyond the series — the two articles below aren’t part of this 5-part series, but pair well with it.