Skip to content
Agile Defense

Curriculum / AI Engineer — AIP Builder

ADVANCEDUnit 6unit-06

Expose it conversationally: AIP Chatbot Studio with safe tools

not started~300 min
Publish a 'Disruption Copilot' chatbot with an Object query tool over the disruption Ontology and a Function tool calling the published recommendation function, using native tool calling.

Introduction

Scenario: Supply-chain analysts want to ask plain-language questions about active disruptions and get a grounded recommendation back without opening AIP Logic themselves. You will expose your governed decision-support capability as a 'Disruption Copilot' chatbot equipped with two least-privilege tools.

By now you have a published recommendation function and an Ontology that models the disruption domain. This unit makes that capability conversational: you will build an AIP Chatbot in AIP Chatbot Studio that lets analysts ask about a late shipment or an at-risk supplier and receive a structured, defensible recommendation. The chatbot is powered by an LLM grounded in the Ontology, documents, and the custom tools you attach, and AIP Chatbot Studio enforces least privilege so the model can reach only what each tool explicitly exposes.

Two tools carry the workflow. An Object query tool lets the chatbot read the disruption Ontology — DisruptionEvent and the Shipment/Supplier context it links to — scoped to only the object types and properties the conversation needs. A Function tool calls your published recommendation function (recommendDisruptionResponse) so the chatbot returns the same governed, structured output (action, rationale, confidence) the rest of your pipeline already trusts, rather than free-styling an answer. Because all four of your candidate tool types — Action, Object query, Function, and Update application variable — are the ones AIP supports for native tool calling, you can prefer native tool calling for reliable, model-driven tool selection.

An important honesty point frames how this unit is verified. AIP Chatbot Studio's tool wiring, prompt, and tool-calling mode are configuration that is not introspectable through a decision-support READ API; only the AIP Agents v2 Get Agent endpoint (in preview) returns an agent's rid, version, and metadata. So you confirm the chatbot exists and was published — and you confirm its Function tool points at a function that is real and executable — but the chatbot's internal tool configuration is verified by you, against the docs and your own configuration, not by an automated check.

Capability focus: AIP Chatbot Studio; Object query + Function tools; native tool calling; least-privilege tool scoping. · Artifact: A published Disruption Copilot chatbot with an Object query tool and a Function tool.

Key concepts

  • AIP Chatbot Studio: The environment for building interactive assistants called AIP Chatbots, powered by an LLM plus the Ontology, documents, and custom tools. Chatbots can be deployed inside the platform and externally via the Ontology SDK and platform APIs, and the studio enforces least privilege so the LLM accesses only what is necessary.
  • AIP Chatbot tool types: The available tools are Action, Object query, Function (call any Foundry function), Update application variable, Command, Request clarification, and a legacy Ontology semantic search. This unit uses an Object query tool (to read the disruption Ontology) and a Function tool (to call the published recommendation function).
  • Native tool calling: A tool-calling mode where the model selects tools directly. It supports only four tool types — Action, Object query, Function, and Update application variable — which is exactly why this chatbot, whose tools fall within those four, can prefer native tool calling for more reliable tool selection.
  • Least-privilege tool scoping: AIP Chatbot Studio scopes each tool so the LLM reaches only the object types, properties, functions, or actions it explicitly exposes. The Object query tool should expose only the disruption object types and properties the conversation needs, not the whole Ontology.
  • AIP Agents v2 Get Agent (preview): The Foundry API endpoint that returns a chatbot's rid, version, metadata, and parameters, defaulting to the latest published version. It requires preview=true and is a preview endpoint, so confirmation is best-effort: absence or an unavailable preview API yields a 'blocked' result rather than a silent pass.
  • Chatbots as functions: AIP Chatbots can be published as Functions and used anywhere Functions execute — including AIP Evals, Automate workflows, and Code Repositories — which is how a chatbot can later become an AIP Evals target. The Function tool here is the inverse direction: the chatbot calling out to your published recommendation function.

Companion video

Tool Use in AIP Agents: Object Queries · open on YouTube

Hands-on activity

each step validates · the unit completes when all steps pass
  1. 1

    Chatbot exists with config/version

    Create the Disruption Copilot chatbot in AIP Chatbot Studio, give it a system prompt that frames it as a supply-chain disruption decision-support assistant grounded in the Ontology, and publish it so a latest published version exists. This step is confirmed by calling AIP Agents v2 Get Agent (preview=true), which returns the chatbot's rid, version, and metadata and defaults to the latest published version. Because that endpoint is in preview, the check is best-effort: if the preview API is unavailable or the agent cannot be found, it reports 'blocked' rather than silently passing, so an absent or unpublished chatbot is never mistaken for a success. The fallback when the preview API is absent is existence-only confirmation or an instructor-attested export of the chatbot configuration.

    not startedinstance check

    Confirms the Disruption Copilot chatbot exists via AIP Agents v2 Get Agent (preview → blocked, never silent pass).

  2. 2

    Function tool targets a runnable published function

    Add a Function tool that calls your published recommendation function, recommendDisruptionResponse, so the chatbot returns the same governed structured output (action, rationale, confidence) the rest of your pipeline relies on instead of improvising an answer. This step verifies that the function the tool targets is real and executable: List Query Types confirms recommendDisruptionResponse is a published query type, and Execute Query (preview=true) runs it on a seeded disruption and confirms the structured keys come back non-empty. Note the honesty boundary — the chatbot's tool wiring itself is not config-introspectable, so the check proves the target function executes correctly, not that the chatbot is internally bound to it; you confirm the binding by configuring it in the studio and testing the conversation.

    not startedinstance check

    Executes the recommendation function the chatbot's Function tool calls and confirms its keys non-empty.

  3. 3

    Object query tool scoped to least-privilege object types

    Add an Object query tool over the disruption Ontology and scope it to least privilege, exposing only the object types and properties the conversation actually needs — DisruptionEvent plus the Shipment and Supplier context it links to — rather than the whole Ontology. This step is self-attested because chatbot tool configuration is not exposed beyond the Get Agent metadata; no READ API enumerates the object types or properties an Object query tool is scoped to. Confirm the scoping yourself in AIP Chatbot Studio against the least-privilege principle, and verify in conversation that the chatbot can read the disruption context it needs and nothing more.

    not startedself-attested

    Self-attested: the Object query tool exposes only the needed disruption object types/properties.

  4. 4

    Native tool calling selected for supported tools

    Set the chatbot to use native tool calling, which is valid here because all of its tools — the Object query tool and the Function tool — fall within the four tool types native tool calling supports (Action, Object query, Function, Update application variable). Native tool calling lets the model select tools directly for more reliable behavior. This step is self-attested: the tool-calling mode is a chatbot configuration setting that is not API-inspectable, so confirm it yourself in the studio and validate by running a few disruption questions to see the model correctly invoke the Object query and Function tools.

    not startedself-attested

    Self-attested: the chatbot uses native tool calling (Action/Object query/Function/Update application variable).