AIYINGFrom AI Awareness to Accomplishment
Showing posts with label APIs. Show all posts
Showing posts with label APIs. Show all posts

Thursday, November 12, 2026

AI Engineering Active Concepts #008 — Tool Calling: Connecting AI Models to Real-World Actions

AI ENGINEERING — ACTIVE CONCEPTS & PRACTICES | #008

Tool Calling: Connecting AI Models to Real-World Actions



Chapter 2: Engineering AI Applications and Agents

AIYING — Accomplishing with AI

The Big Idea: A language model can generate a proposed action, but an application must execute that action through an authorized tool.

Tool calling connects language-model reasoning and interpretation with APIs, databases, enterprise software, and operational workflows.

Engineering question: How do we allow AI systems to use external capabilities without surrendering control over what they can do?

Contents

  1. Why Tool Calling Matters
  2. UNDERSTAND — The Concept
  3. CONNECT — The AI Engineering Ecosystem
  4. The Tool Calling Lifecycle
  5. APPLY — Enterprise Procurement Assistant
  6. Worked Example: Purchase Order Status
  7. Engineering Decisions and Trade-offs
  8. Active Industry Practices
  9. ACCOMPLISH — Practical Exercise
  10. Student and Practitioner Project
  11. Check Your Understanding
  12. Active Connections
  13. References and Further Reading

1. Why Tool Calling Matters

Imagine a procurement manager asking an AI assistant:

"Check purchase order PO-1048. If delivery is delayed, prepare a supplier follow-up."

A conventional chatbot might explain how to check a purchase order manually.

A tool-enabled AI application can retrieve current order information from an authorized enterprise system and prepare a follow-up based on the result.

However, generating a tool call is not the same as executing it.

The application must validate the request, enforce permissions, invoke the tool, inspect the result, and decide whether further action is appropriate.

Tool calling turns AI from a system that only generates responses into a component that can participate in controlled business workflows.

↑ Back to Contents

2. UNDERSTAND — The Concept

What is tool calling?

Tool calling is a mechanism through which an AI model produces a structured request for an external capability made available by an application.

A tool might be a function, API endpoint, database query, search service, calculator, or enterprise workflow operation.

The application typically executes the requested operation and returns the result to the model or workflow controller.

Three essential components

ComponentResponsibility
AI modelInterprets the request and proposes a tool call with arguments
Application or orchestratorValidates, authorizes, executes, and monitors tool operations
External toolPerforms the actual lookup, computation, or authorized action

Common categories of tools

  • Information retrieval: Search knowledge bases or enterprise records.
  • Computation: Calculate values or transform data.
  • Read-only operations: Retrieve order status or inventory levels.
  • Write operations: Create tickets, update records, or schedule tasks.
  • Communication: Prepare or send messages through approved services.
  • Workflow operations: Initiate controlled business processes.

Tool calling versus structured outputs

Structured outputs define the format of model-generated data.

Tool calling uses structured arguments to request a specific external operation.

The two concepts are related, but tool calling introduces additional requirements involving execution, permissions, errors, and external side effects.

Tool calling versus an AI agent

Tool calling is a capability. An AI agent is an application architecture that may use tools, state, planning, and repeated decisions to pursue a task.

A single tool call does not automatically make an application an autonomous agent.

↑ Back to Contents

3. CONNECT — The AI Engineering Ecosystem

Connected ConceptRelationship
Structured OutputsDefines machine-readable tool arguments
JSON SchemaSpecifies required parameters and permitted types
Context EngineeringProvides the tool descriptions and task context
APIsExpose external software capabilities
AI AgentsCoordinate tool use across multiple steps
Workflow StateRecords completed actions and pending operations
MCPStandardizes ways for applications to discover and use external tools and context
ObservabilityRecords execution outcomes, latency, and failures
EvaluationTests tool selection, argument accuracy, and task completion
Security and GovernanceEnforce permissions, approval requirements, and accountability

Active connection: Tool calling brings together model capabilities and conventional software engineering disciplines.

↑ Back to Contents

4. The Tool Calling Lifecycle

User Request

↓

Model Receives Available Tool Definitions

↓

Model Proposes Tool and Arguments

↓

Application Validates and Authorizes

↓

Tool Executes

↓

Application Receives Result

↓

Model or Workflow Processes Result

↓

Verified Response or Next Authorized Action

Step 1 — Register tool definitions

The application describes the available tools, including their names, purposes, and input schemas.

Step 2 — Interpret the user request

The model determines whether a tool is useful and, where supported, produces structured arguments.

Step 3 — Validate and authorize

The application checks argument types, user permissions, allowed operations, and business constraints.

Step 4 — Execute the operation

The application invokes the tool using appropriate credentials and error handling.

Step 5 — Process the result

The result is checked and returned to the model or orchestration logic.

Step 6 — Respond or continue

The system reports the outcome or requests another authorized operation.

Tool results are external data, not automatically trusted instructions.

↑ Back to Contents

5. APPLY — Enterprise Procurement Assistant

Scenario: Purchase Order Follow-Up

A manufacturing company manages hundreds of purchase orders across suppliers.

Procurement teams need to identify delays and coordinate follow-up actions.

A user asks:

"Check PO-1048. If the shipment is delayed, prepare a follow-up task for the procurement team."

Approach A — Conversational assistant

The AI explains how to check an ERP system and create a follow-up task.

The user must complete the steps manually.

Approach B — Tool-enabled assistant

The application exposes two authorized tools:

  • get_purchase_order: Retrieves current purchase-order information.
  • create_followup_task: Creates a procurement task after validation and required approval.

The assistant retrieves the order status, checks whether a delay is indicated, and prepares a task request.

The application determines whether the task may be created automatically or requires human confirmation.

Engineering outcome

Tool calling can reduce manual navigation between systems and support more responsive workflows.

But reliable implementation requires accurate records, access control, approval policies, and confirmation of actual tool execution.

↑ Back to Contents

6. Worked Example: Purchase Order Status

The following is a fictional demonstration. No real ERP system is accessed.

Tool definition

{
  "name": "get_purchase_order",
  "description": "Retrieve an authorized purchase order",
  "parameters": {
    "type": "object",
    "properties": {
      "po_id": {"type": "string"}
    },
    "required": ["po_id"],
    "additionalProperties": false
  }
}

This is a conceptual tool definition. Provider-specific APIs may require a different wrapper or additional fields.

Model-generated tool request

{
  "name": "get_purchase_order",
  "arguments": {
    "po_id": "PO-1048"
  }
}

Illustrative tool response

{
  "po_id": "PO-1048",
  "supplier": "Example Components Ltd",
  "status": "delayed",
  "expected_delivery": "2026-11-18",
  "revised_delivery": "2026-11-23"
}

Next proposed action

The application may prepare a follow-up task based on the confirmed order status.

{
  "name": "create_followup_task",
  "arguments": {
    "po_id": "PO-1048",
    "reason": "Delivery delayed",
    "assigned_team": "procurement"
  }
}

The application must verify authorization and any approval requirement before executing this write operation.

Possible final response

"PO-1048 is marked delayed. The expected delivery date changed from 18 November to 23 November 2026. A procurement follow-up task has been prepared and is awaiting approval."

Important distinction: The assistant must not claim that a task was created unless the external system confirms successful creation.

↑ Back to Contents

7. Engineering Decisions and Trade-offs

DecisionPotential BenefitRisk or Trade-off
Expose more toolsBroader functionalityGreater selection complexity and attack surface
Read-only toolsLower operational riskLimited ability to complete workflows
Write-enabled toolsGreater automationPossibility of unintended changes
Automatic executionLower latencyReduced opportunity for human intervention
Approval gatesStronger controlAdditional workflow time
Parallel tool callsFaster independent operationsConcurrency and dependency complexity
RetriesRecovery from transient failuresDuplicate side effects without safeguards
Detailed loggingAuditability and debuggingStorage and sensitive-data exposure risks

Important failure modes

  • Incorrect tool selection
  • Invalid or invented arguments
  • Unauthorized access to external data
  • Prompt injection through tool results
  • Duplicate write operations after retries
  • Partial completion of multi-step workflows
  • Stale or inconsistent external information
  • False claims of successful execution

Recommended controls

  • Least-privilege credentials and user-scoped authorization
  • Schema and business-rule validation
  • Human approval for consequential actions
  • Timeouts, bounded retries, and rate limits
  • Idempotency keys where supported for write operations
  • Audit logs with appropriate sensitive-data protection
  • Verification of actual execution results
  • Clear separation between untrusted tool content and instructions
The model may propose an action. The application must remain responsible for deciding whether, how, and when it is executed.

↑ Back to Contents

8. Active Industry Practices

Established practices

  • Function and tool calling through model APIs
  • JSON-schema-based argument definitions
  • Integration with enterprise APIs
  • Application-side validation and execution
  • Tool error handling and execution logging
  • Human approval for sensitive operations

Evolving practices

  • MCP-based tool integration
  • Dynamic tool discovery and selection
  • Multi-step agent orchestration
  • Tool execution sandboxing
  • Fine-grained policy enforcement
  • Tool-use evaluation and trace analysis

Industry applications

Tool calling is used in customer support, software development, financial operations, procurement, enterprise search, data analysis, scheduling, and workflow automation.

Practice status: Established AI application capability with rapidly evolving protocols and orchestration practices.

Reviewed: November 2026.

↑ Back to Contents

9. ACCOMPLISH — Practical Exercise

Exercise: Design a Tool-Enabled Procurement Assistant

Use the following fictional purchase-order information:

PO: PO-2056

Supplier: Example Industrial Supplies

Status: Delayed

Original delivery: 20 November 2026

Revised delivery: 26 November 2026

Your tasks

  1. Define a read-only tool to retrieve purchase-order information.
  2. Specify its required input arguments.
  3. Design an illustrative tool response.
  4. Define a second tool for preparing follow-up tasks.
  5. Identify which operation requires authorization or approval.
  6. Describe how the application handles a failed tool call.
  7. Explain how duplicate task creation should be prevented.
  8. Prepare a final user response that accurately reflects the execution status.

Reusable AI-assisted prompt

Act as an AI application engineer.

Design a tool-calling workflow for an
enterprise procurement assistant.

The user wants to check a purchase order
and prepare a follow-up if delivery is delayed.

Provide:
1. Required tools and descriptions.
2. JSON input schemas.
3. Example tool requests and responses.
4. Validation and authorization checks.
5. Human approval requirements.
6. Failure and retry handling.
7. Audit information to capture.
8. A safe final user response.

Use fictional data.
Do not claim that any external action
has actually been executed.

Accomplishment: Design a controlled tool-calling workflow that separates model decisions from authorized software execution.

↑ Back to Contents

10. Student and Practitioner Project

Mini Project: Tool-Enabled Procurement Assistant

Objective: Prototype an AI application that retrieves purchase-order data and prepares follow-up tasks using simulated tools.

Project requirements

  1. Create a fictional purchase-order dataset.
  2. Define two or three tools with input schemas.
  3. Implement a read-only purchase-order lookup.
  4. Implement a simulated task-creation operation.
  5. Validate tool arguments before execution.
  6. Introduce approval checks for write operations.
  7. Simulate timeouts and invalid arguments.
  8. Prevent duplicate task creation during retries.
  9. Record tool calls, outcomes, and execution status.
  10. Evaluate the system using representative user requests.

Suggested evaluation measures

MetricWhat It Measures
Tool selection accuracyWhether the appropriate tool is chosen
Argument accuracyWhether tool parameters match the request
Authorization complianceWhether prohibited operations are blocked
Task completion rateWhether authorized tasks finish successfully
Duplicate action rateWhether retries cause repeated side effects
Execution latencyTime spent invoking and processing tools
Outcome reporting accuracyWhether responses match actual tool results

Deliverable: A working prototype or design, tool definitions, sample execution traces, test results, and a short engineering recommendation.

↑ Back to Contents

11. Check Your Understanding

  1. What is tool calling in an AI application?
  2. Who actually executes a model-proposed tool call?
  3. How is tool calling different from structured outputs?
  4. Why does a tool-enabled application need authorization checks?
  5. What is the difference between read-only and write-enabled tools?
  6. Why are retries risky for operations with side effects?
  7. How does MCP relate to tool integration?
  8. How would you evaluate tool-calling reliability?

Reflection: If an AI assistant correctly identifies a delayed order but the task-creation API fails, what should the assistant tell the user?

↑ Back to Contents

12. Active Connections

Coming next — #009: Model Context Protocol (MCP): Standardizing AI Connections to Tools and Data.

↑ Back to Contents

13. References and Further Reading

  1. OpenAI — Function Calling
  2. OpenAI — Structured Outputs
  3. Model Context Protocol — Introduction
  4. Anthropic — Tool Use
  5. OWASP — Security Risks for LLM Applications

Tool-calling APIs, provider-specific schemas, and integration protocols evolve. Verify current documentation before production implementation.


Final Takeaway

Tool calling connects AI reasoning with real-world capabilities. Reliable engineering ensures that every proposed action is validated, authorized, executed safely, and reported accurately.

AI Engineering — Active Concepts & Practices
Active Concept #008 — Tool Calling

AIYING — Accomplishing with AI

Understand → Connect → Apply → Accomplish

Monday, October 5, 2026

The Minimalist API — APIs Explained in 100 Words

```html

The Minimalist API — APIs Explained in 100 Words

APIs power much of the connected digital world. They allow applications, services, data and increasingly AI systems to communicate and work together. The Minimalist API explains the essential ideas behind APIs through ten concepts, each beginning with exactly ten words.

10 ideas × 10 words = 100 words.


Why This Book?

Every time one application requests information or functionality from another, an API may be involved.

Weather applications retrieve forecasts. Payment applications communicate with payment services. AI applications connect to models. Business systems exchange data.

You do not need to be a programmer to understand the basic idea. An API is fundamentally a structured way for software systems to communicate.


How to Read This Book

Start with the bold ten-word sentence under each idea. Together, these ten sentences form the entire book in exactly 100 words.

The explanation underneath each sentence adds context and helps you understand how the idea works in practice.


1. API

APIs let different software systems communicate through defined interfaces reliably.

API stands for Application Programming Interface. It provides an agreed way for one software system to interact with another without needing to understand how that system works internally.


2. Interface

Interfaces define how software components request and exchange information consistently.

Think of an interface as an agreement between systems. It specifies what can be requested, what information must be supplied and what kind of response can be expected.


3. Endpoint

Endpoints provide specific locations where API requests are received remotely.

An endpoint represents a particular API capability or resource. Different endpoints may be used to retrieve users, submit orders, generate text, access records or perform other actions.


4. Request

Requests tell APIs what information or action clients need next.

The requesting application sends instructions to the API. A request can contain parameters, identifiers, instructions, data and authentication information needed to perform the operation.


5. Response

Responses return requested data, results, status, or useful error information.

After processing a request, the API sends a response. The response may contain requested information, the result of an action, a status indicator or an explanation of why the request could not be completed.


6. Method

Methods indicate whether clients retrieve, create, update, or delete resources.

Web APIs commonly use methods such as GET, POST, PUT, PATCH and DELETE. These methods communicate the type of operation the requesting system wants performed.


7. Authentication

Authentication verifies who may securely access protected API capabilities remotely.

APIs often need to know who is making a request. API keys, tokens and other authentication mechanisms help control access and protect systems from unauthorized use.


8. Data

APIs commonly exchange structured data using formats such as JSON.

Structured formats allow different systems to interpret exchanged information consistently. JSON is widely used because it is lightweight, readable and easy for software to process.


9. Documentation

Documentation explains available endpoints, parameters, responses, limits, and usage requirements.

Good API documentation tells developers how to use the interface correctly. It normally describes available capabilities, required inputs, example requests, expected responses and possible errors.


10. Integration

APIs connect capabilities, enabling applications to accomplish more together efficiently.

This is the larger purpose of APIs. Instead of building every capability from scratch, applications can connect to existing services and combine their capabilities into new products, workflows and experiences.


The Entire Book in 100 Words

APIs let different software systems communicate through defined interfaces reliably.

Interfaces define how software components request and exchange information consistently.

Endpoints provide specific locations where API requests are received remotely.

Requests tell APIs what information or action clients need next.

Responses return requested data, results, status, or useful error information.

Methods indicate whether clients retrieve, create, update, or delete resources.

Authentication verifies who may securely access protected API capabilities remotely.

APIs commonly exchange structured data using formats such as JSON.

Documentation explains available endpoints, parameters, responses, limits, and usage requirements.

APIs connect capabilities, enabling applications to accomplish more together efficiently.


Closing

An API is more than a technical connection.

It is a contract for collaboration between software systems.

One system makes a request. Another provides a response. The interface makes the interaction predictable.

Once you understand interface → endpoint → request → response, the basic architecture of APIs becomes surprisingly simple.

And in the age of AI, APIs become even more important: they allow applications, agents, models, tools and organizational systems to connect and accomplish work together.


The Minimalist Series

Everything AI. For Everyone.

The Minimalist Series explains important ideas using one simple discipline:

10 essential ideas × 10 words = 100 words.

Explore The Minimalist Series and related books at:
https://dastikop.blogspot.com

Ravindra Dastikop
AI Educator, Advisor & Mentor

```

Accomplish with AI

Powered by Blogger.

Featured post

AI Engineering Hands-On Lab #001 — Build an AI Answer Reliability Test Bench Without Code

AIYING | Daily 24 — Post 009 AI Engineering Hands-On Lab #001 Build an AI Answer Reliability Test Bench — Without Writing Code Lea...

Search This Blog

List of blogs

Search This Blog

About

Translate

Instant Stories

Read in Your Language

Test

share this

ShareThis

Popular Posts