We ran a webinar last week on building agentic workflows in Foundry – walking through the tooling you can reach for (Chatbot Studio, AIP Logic, Agent Flow etc.) and how to wire them together.
The interesting part wasn’t the tooling overview. It was the questions that came after, once people started thinking about what happens when these agents actually run in production. How does an agent behave when it’s writing data, not just returning an answer? Where is it even running if it’s exposed as a function? What breaks when a workflow runs longer than five minutes? How do you keep sessions and permissions sane?
Those are the questions we’re answering below. They came straight from the session, and they’re the ones worth getting right before you publish.
An agent is not necessarily a pure function that receives an input and returns a complete answer. The function-shaped interface is often the entry point into an agent loop. During that loop, the agent can query Foundry, call tools and functions, and trigger actions if it has permission. Agents typically have access to an OSDK client with provided ontology entities, Ontology + Palantir MCP (with permissions scoped to its function), and any other logic defined in the repo.
Those writes or external calls are the side effects. They may not be represented in the function return value. A safer production pattern separates:
- Reasoning: the agent proposes what should happen.
- Execution: a function, action, or orchestrator applies the change.
- Verification: a human, validator, or eval checks the outcome.
For write-heavy workflows, consider having the agent return a typed proposal and letting a deterministic post-hook or orchestrator own persistence.
The emerging Agent primitive treats a session as the durable record of a run, including messages, tool calls, tool results, and typed state.
2. Where are these agents running if they are running as functions?
“Function” describes how the agent is invoked, not necessarily the full runtime.
- FCS-based Agent Flow templates: Function Executor forwards the request to Foundry Container Service, which starts a container and runs the agent asynchronously.
- Deployed Functions: a long-running Compute Module hosts an HTTP server. Synchronous requests can still hit request timeouts unless the async path is used.
- Durable serverless functions: the longer-term direction is Orchestrator-backed durable execution, where LLM and tool calls are checkpointed across shorter invocations.
A function-shaped API can therefore launch a stateful, asynchronous, side-effecting workflow. It does not imply pure query semantics.
3. How should I deploy an agent that runs longer than five minutes?
The answer depends on the runtime:
- With the current FCS-based Agent Flow template, the agent run is decoupled from the synchronous function request, so it is not limited in the same way as a normal serverless TypeScript function.
- With a Deployed Function, use the async function execution path instead of holding one synchronous request open. Current guidance identifies Automate as the main platform surface supporting this path; other entry points may require a custom UI.
Do not start background work inside a normal serverless function and return immediately. That fire-and-forget pattern makes tracking, retries, cleanup, and reliability difficult. Also check token lifetime and action permissions independently.
4. Can a pro-code agent be imported into the React SDK now?
You should be able to import the published agent function into an OSDK React app: this should be possible when it is registered and published as an Ontology function.
Practical checks:
- Publish the function before generating the OSDK.
- Regenerate or update the SDK after publishing a new function version.
- Confirm the function API name and ontology RID.
- If a void return type causes an SDK issue, update to the newer agent template/bundle where the output is represented as an optional string.
5. How should I manage sessions? Should I send the full transcript every time?
Do not resend the full transcript on every query unless the conversation is short and temporary.
Prefer a persistent session ID or analysis ID. For a custom implementation, store messages, artifacts, and structured state outside the prompt, then send only the current turn, relevant retrieved context, and a summary or checkpoint. Full transcripts increase cost, latency, and context growth.
6. How should I set up Foundry/MCP with a specific server identity and tightly scoped access?
Separate the identity models:
- Local developer workflow: use Palantir MCP with the developer’s user OAuth identity. This gives the local agent the user’s access, but the local IDE or agent harness becomes part of the governance boundary.
- Deployed/shared workflow: use Ontology MCP through a scoped application or the Agent Flow project’s permission boundary. Grant only the required projects, object types, links, functions, and actions.
A server identity and a user identity are not automatically the same. Use user authentication or an explicit on-behalf-of design when you need per-user row-level permissions and auditability. Use a narrowly scoped service/agent identity for headless work, but do not treat it as equivalent to every user’s permissions.
The current Agent Flow direction is to consolidate OSDK/OMCP permissions in the agent repository’s project. Some templates may still use a Developer Console application or service user, so verify the runtime.