• Documentation
    • Search documentation
    karat

    +

    K

    API Reference ↗
    AnnouncementsAugust 2026

    Announcements

    REMINDER: Sign up for the Foundry Newsletter to receive a summary of new products, features, and improvements across the platform directly to your inbox. For more information on how to subscribe, see the Foundry Newsletter and Product Feedback channels announcement.

    Share your thoughts about these announcements in our Developer Community Forum ↗.

    Process two streams with custom logic using CoProcess user-defined functions in Pipeline Builder

    Date published: 2026-08-13

    CoProcess user-defined functions (UDFs) are now supported in Pipeline Builder. A keyed CoProcess UDF allows users to define custom stateful logic for processing events from two different streams and merging them into a single output stream.

    A keyed CoProcess UDF takes a separate stream on each of its left and right inputs.

    A keyed CoProcess UDF takes a separate stream on each of its left and right inputs.

    Rows can be processed and emitted from either stream, which allows sophisticated real-time pipelines that go beyond standard join patterns. As with any stateful UDF, keyed CoProcess UDFs can be imported into a pipeline and used like any other transform.

    Configure a keyed CoProcess UDF by mapping the columns of each input to the UDF.

    Configure a keyed CoProcess UDF by mapping the columns of each input to the UDF.

    What's new

    With keyed CoProcess UDFs, you can:

    • Maintain custom state across both input streams. State is shared between the two inputs rather than scoped to a single stream.
    • Emit output rows from either stream independently. Neither stream has to wait on the other to produce output.
    • Implement complex matching logic that standard joins cannot express.

    Example use cases

    • Flight tracking: Join a stream of live aircraft positions with flight plan schedule updates to detect route deviations in real time.
    • Supply chain: Join shipment tracking events with inventory updates to suggest restocking before a warehouse runs out.
    • Wildfire alerting: Join satellite thermal detections with ground-level weather data to escalate alerts when hotspots coincide with high-risk conditions.

    Share your feedback

    As we continue to add features to Pipeline Builder, we want to hear about your experiences and welcome your feedback. Share your thoughts with Palantir Support channels or our Developer Community using the pipeline-builder tag ↗.

    Observe and optimize your agents, objects, and workflows with object timeline

    Date published: 2026-08-11

    The new object timeline feature provides observability into actions performed on an object. See edits performed by agents or by manual action along with full attribution for each one. Monitor token usage, runtime, and agentic coverage to find where to optimize. Trace any edit back to the execution that made it.

    Object timeline showing edits to an object with attribution token usage runtime and change costs.

    Object timeline showing edits to an object, with attribution, token usage, runtime, and change costs.

    View a demonstration of object timeline on the Palantir Developers YouTube channel. ↗.

    Summary metrics

    The object's summary metrics give you a starting point for optimization:

    • Total token usage: The number of tokens consumed across all executions.
    • Total runtime: The length of time from the first to the last execution.
    • Waiting time: The amount of time spent waiting for human input, shown in the same cell as total runtime.
    • Agentic coverage: How much of the object's history was driven by agents versus humans.

    Explore the timeline

    Each row represents an agent, human, or resource. Bars show each execution, and diamond markers show each edit made to the object in the ontology through an action. Together, the timeline shows how each has worked on the same object over time, including where activity overlapped or one picked up from another.

    Select any bar or diamond to open a side panel with the metrics for that execution and the edits it made to the object.

    Optimize your workflow

    • Token usage per step lets you quickly identify which steps consume the most, so you know where to focus, whether to refine your prompt or switch models. Select any diamond on the timeline to view detailed metrics.
      • Easily spot that most of the token usage in this use case comes from the agent that creates a new campaign. At a glance, you can see where to prioritize optimization, whether that is refining the prompt, switching models, or reducing token usage another way.
    • Time breakdown helps you spot where you are losing time in a run, so you can identify manual steps to automate and reduce overall workflow duration.

    This notional example shows that 98 of the time is spent waiting on human input for the final review. Knowing this metric can help you understand where you can intervene to speed up the runtime.

    The notional example above shows that 98% of the time is spent waiting on human input for the final review. Knowing this metric can help you understand where you can intervene to speed up the runtime.

    Access object timeline from Autopilot or Object Explorer

    You can access object timeline from Autopilot, as well as from Object Explorer if edit history is turned on.

    Access the object timeline from Autopilots graph view or from the More menu in Object Explorer.

    Access the object timeline from Autopilot's graph view or from the More menu in Object Explorer.

    Share your feedback

    As we continue to add features to Autopilot, we want to hear about your experiences and welcome your feedback. Share your thoughts with Palantir Support channels or our Developer Community ↗ using the aip-autopilot tag ↗.

    Additional open-weight models now available in AIP through AWS Bedrock

    Date published: 2026-08-04

    Select models from DeepSeek, Z.ai, and Moonshot AI are now available in AIP through AWS Bedrock on non-georestricted, US, EU, UK, and JP commercial enrollments.

    Model overviews

    DeepSeek V3.2 ↗ is DeepSeek's mixture-of-experts reasoning model optimized for reasoning, coding, and instruction following. It supports client-side tool use and a 164,000-token context window with up to 8,000 output tokens.

    GLM 5 ↗ is Z.ai's multimodal reasoning model, designed for coding, multilingual understanding, and agentic workflows. It supports text and image inputs, client-side tool use, and a 256,000-token context window with up to 16,000 output tokens.

    Kimi 2.5 ↗ is Moonshot AI's frontier-class reasoning model, optimized for complex systems engineering and long-horizon agentic tasks. It supports advanced reasoning, mathematics, coding, and client-side tool use, with a 200,000-token context window and up to 128,000 output tokens.

    Getting started

    To use these models:

    Your feedback matters

    We want to hear about your experiences using language models in the Palantir platform and welcome your feedback. Share your thoughts with Palantir Support channels or on our Developer Community ↗ using the language-model-service tag ↗.

    Introducing SuperRepo: Build full-stack Ontology applications in a pro-code monorepo

    Date published: 2026-08-04

    SuperRepo cover image.

    As of the week of August 3, SuperRepo is now available in beta, bringing a pro-code way to build complex full-stack applications anchored around the Ontology. A SuperRepo is a single monorepo that holds your Ontology definitions, your functions, and your React application together, so you can develop, build, and deploy them as one versioned artifact.

    With SuperRepo, you ship a feature that spans the Ontology, a function, and a frontend from one repository, in a single edit-and-preview cycle.

    Iterate across the whole application locally

    The Foundry CLI runs your SuperRepo on your own machine so you can change the Ontology, your functions, and your application together:

    • Ontology-as-code: Declare object types, links, interfaces, and actions in TypeScript. Your code definitions are the source of truth, and they materialize as real entities on your enrollment when your product is deployed.
    • Embedded Ontology preview: Local servers reproduce the Ontology's behavior on your machine. Function-backed actions route through the embedded Ontology, and functions run in language-specific preview runtimes. Seed data files populate a fresh local database each time the server starts.
    • Locally generated Ontology SDK: SDK bindings are generated from your Ontology-as-code definitions and regenerated automatically whenever those definitions change, then consumed directly by your functions and your Ontology SDK application. You can extend the Ontology and use the new types in a single loop, with no SDK republish in between.

    Track Ontology SDK rebuild progress in the ontology section of the preview output.

    Track Ontology SDK rebuild progress in the ontology section of the preview output.

    Deploy programmatically to any enrollment

    A SuperRepo compiles natively into a Marketplace product: a self-contained, reproducible, and cryptographically signed bundle you can install on one or more enrollments. Run foundry deploy configure once to map your deployment inputs into an env.yml file, commit it, and both deployment paths read the same configuration:

    • From the Palantir platform: If your source is hosted in the platform, tag a version of your repository and Foundry CI builds and deploys the product for you.
    • From your own CI system: If your source is hosted elsewhere, build and deploy from your terminal or from any CI provider, such as GitHub Actions or CircleCI, with the Foundry CLI.

    The interactive foundry deploy configure flow writes your deployment configuration to env.yml

    The interactive foundry deploy configure flow writes your deployment configuration to env.yml.

    Use the Ontology you already have

    A SuperRepo does not require a separate Ontology. Entities that already exist on your enrollment, including those built in the Ontology Manager, can be imported into your SuperRepo instead of being redefined in code, and types created in code are visible in the UI. Applications are never siloed by how their Ontology types were created.

    Getting started

    Create a SuperRepo in whichever environment you prefer:

    Then follow the end-to-end tutorial to import an object type, define a link type, add a TypeScript function, expose it as a function-backed action, and consume all of it from a React application without leaving your editor. When you are ready to install on an enrollment, review Prepare for your first deployment.

    Learn more about SuperRepo in our documentation.

    What is coming next

    The following are in active development and not available yet:

    Review Coming in the future and the FAQ for details.

    We want to hear from you

    We welcome your feedback on SuperRepo, and your posts help the team prioritize what to build next. Share your thoughts with Palantir Support channels or our Developer Community ↗ using the superrepo ↗ tag.