Tuesday, November 10, 2026
Saturday, October 3, 2026
The Minimalist Function Calling: Function Calling Explained in 100 Words
THE MINIMALIST FUNCTION CALLING
Function Calling Explained in 100 Words
Ravindra Dastikop
Understand less. Accomplish more.
Why This Book?
Function calling can sound complicated.
Tools.
Functions.
Schemas.
Arguments.
Selection.
Execution.
Results.
Validation.
Actions.
Judgment.
But using function calling does not have to begin with complexity.
This book strips function calling down to what matters.
10 ideas.
10 words each.
100 words.
Enough to begin.
How to Read This Book
Read one idea.
Stop.
Think about it.
Try it with AI.
Then move to the next.
The purpose is not to know everything about function calling.
The purpose is to understand enough to accomplish something with function calling.
01 — FUNCTION CALLING
Function calling lets AI models request functions using structured arguments.
Normally, a model generates a response.
Function calling gives it another possibility.
Instead of merely describing what should happen, the model can request a function made available by an application.
Imagine asking:
“What is the status of order 4821?”
The model itself may not know.
But an application could provide a function such as:
get_order_status
The model can recognize that the function is useful and request it with the appropriate order number.
The important distinction is:
The model requests the function.
The application executes it.
02 — TOOLS
Tools extend models beyond generation by connecting with external capabilities.
Language generation is powerful.
But many useful tasks require capabilities outside the model.
For example:
Retrieve customer information.
Check inventory.
Create a support ticket.
Calculate shipping.
Search company systems.
Update an application.
Function calling allows application-defined functions to become tools available to the model.
This changes the model from something that can only say what should happen into part of a system that can help determine which capability should be used.
03 — FUNCTIONS
Functions define operations applications make available for models to request.
A function represents something the application knows how to do.
For example:
get_weather
find_customer
check_inventory
create_ticket
calculate_price
Each function should have a clear purpose.
The model needs enough information to understand what the function does and when it is appropriate.
The application decides which functions are available.
The model can determine when an available function may help accomplish the task.
04 — SCHEMAS
Schemas describe function arguments so models can generate structured inputs.
A function needs more than a name.
It needs to describe the information it expects.
Suppose we have:
get_weather
The function might require:
Location.
Unit.
Date.
A schema defines the expected structure of those arguments.
For example:
location → string
unit → Celsius or Fahrenheit
This gives the model a structured contract for constructing the function request.
Clear schemas can make function calls more predictable and easier for applications to process.
05 — ARGUMENTS
Arguments contain structured values the model supplies when requesting functions.
Once the model chooses a function, it needs to provide the required information.
Consider:
get_weather(location)
If the user asks:
“What is the weather in Bengaluru?”
The model might request the function with:
location = Bengaluru
That value is an argument.
Arguments translate information from the conversation into structured input that application code can use.
This is an important transition.
Natural language becomes machine-processable parameters.
06 — SELECTION
Selection determines whether models choose available functions automatically or explicitly.
Giving the model functions does not mean every function must always be used.
Sometimes the model can decide whether a tool is necessary.
Sometimes the application may constrain or specify which function can be called.
Consider:
“Hello.”
No external function may be needed.
But:
“Check whether product X is in stock.”
may require an inventory function.
Function selection therefore connects the user's intention with the capability most appropriate for accomplishing it.
07 — EXECUTION
Execution happens in application code after models request function calls.
This distinction is essential.
The model does not automatically execute your application function merely because it generated a function call.
The model produces a request.
Your application receives it.
Your code examines the request.
Then the application executes the corresponding operation.
For example:
Model requests → get_inventory(product_id)
Your application might then query:
A database.
An API.
An enterprise system.
Another service.
The application remains responsible for actually performing the operation.
08 — RESULTS
Results return outputs to models for continued reasoning and responses.
Execution produces something.
Suppose the application checks inventory and receives:
17 units available.
That result can be returned to the model.
The model now has information it did not previously possess.
It can continue the interaction and answer:
“There are currently 17 units available.”
This creates a loop.
The model identifies a need.
It requests a function.
The application executes it.
The result returns.
The model continues.
09 — VALIDATION
Validation checks model generated arguments before applications perform requested operations.
Function calls are generated by AI.
They should not automatically be treated as trustworthy instructions.
Arguments may be:
Missing.
Incorrect.
Unexpected.
Unauthorized.
Unsafe.
Inconsistent with application rules.
The application should therefore validate inputs before performing operations.
This becomes particularly important when functions can:
Change records.
Send messages.
Spend money.
Delete information.
Access sensitive systems.
Create other real-world consequences.
Function calling connects AI with action.
Validation helps create a boundary before action occurs.
10 — JUDGMENT
Judgment determines which functions, permissions, and actions remain appropriate overall.
Function calling can make AI systems substantially more capable.
But greater capability also creates greater responsibility.
Developers and organizations must decide:
Which functions should exist?
Which functions should the model access?
What permissions should they receive?
Which actions need approval?
What information can functions expose?
Which operations require human confirmation?
The goal is not to give AI every possible capability.
The goal is to provide the right capability with the right boundaries.
The Entire Book in 100 Words
FUNCTION CALLING
Function calling lets AI models request functions using structured arguments.
TOOLS
Tools extend models beyond generation by connecting with external capabilities.
FUNCTIONS
Functions define operations applications make available for models to request.
SCHEMAS
Schemas describe function arguments so models can generate structured inputs.
ARGUMENTS
Arguments contain structured values the model supplies when requesting functions.
SELECTION
Selection determines whether models choose available functions automatically or explicitly.
EXECUTION
Execution happens in application code after models request function calls.
RESULTS
Results return outputs to models for continued reasoning and responses.
VALIDATION
Validation checks model generated arguments before applications perform requested operations.
JUDGMENT
Judgment determines which functions, permissions, and actions remain appropriate overall.
The Minimalist Function Calling
You do not need to understand every function-calling implementation before you begin.
Remember ten things:
Function Calling.
Tools.
Functions.
Schemas.
Arguments.
Selection.
Execution.
Results.
Validation.
Judgment.
Everything else can come later.
Define the capability.
Describe the function.
Create the schema.
Supply the tool.
Let the model select appropriately.
Receive structured arguments.
Validate them.
Execute the function.
Return the result.
Apply human judgment.
Then accomplish something.
One Final Question
The next time you build an AI application, don't begin with:
“What should the model say?”
Begin with:
“What should the model be able to ask my application to do?”
Then give it the right tools.
The Minimalist Responses API: Responses API Explained in 100 Words
THE MINIMALIST RESPONSES API
Responses API Explained in 100 Words
Ravindra Dastikop
Understand less. Accomplish more.
Why This Book?
The Responses API is becoming complicated.
Inputs.
Models.
Outputs.
Tools.
Conversations.
Multimodal.
Streaming.
State.
Judgment.
But using the Responses API does not have to begin with complexity.
This book strips the Responses API down to what matters.
10 ideas.
10 words each.
100 words.
Enough to begin.
How to Read This Book
Read one idea.
Stop.
Think about it.
Try it with AI.
Then move to the next.
The purpose is not to know everything about the Responses API.
The purpose is to understand enough to accomplish something with the Responses API.
01 — RESPONSES
Responses provides OpenAI's unified interface for building intelligent applications today.
The Responses API is a central OpenAI API surface for building applications with models.
You send input.
Choose a model.
Give it instructions.
Optionally provide tools.
The model processes the request.
The API returns a response.
A response can involve more than generated text.
It can include messages, reasoning, tool calls, and other output items.
The important shift is simple.
You describe what needs to be accomplished and let the model work through the available capabilities.
02 — INPUT
Input supplies text, images, files, or other information for processing.
Every response begins with input.
Input tells the model what it has to work with.
That might include:
Text.
Images.
Files.
Instructions.
Previous interaction items.
Information returned from tools.
Good input gives the model useful material for accomplishing the task.
The important question is:
What information does the model need to do this work?
03 — MODEL
Models process supplied inputs and generate useful outputs or actions.
The model provides the intelligence behind the response.
It processes the supplied input.
Interprets instructions.
Works with available context.
Reasons when appropriate.
Generates output.
And may decide to use available tools.
The API provides the interface.
The model performs the intelligence work.
04 — OUTPUT
Output contains generated messages, tool calls, and other response items.
A response is not necessarily one block of text.
The Responses API can return different kinds of output items.
These can represent:
Messages.
Reasoning.
Tool calls.
Function calls.
Other response items.
This matters because an AI application may need to do more than display an answer.
It may need to interpret an item.
Execute a tool.
Continue a workflow.
Or present the final result.
05 — TOOLS
Tools extend models with search, files, code, computers, and MCP.
Models can generate information.
Tools let them do more.
Depending on the model and configuration, tools can provide capabilities such as:
Web search.
File search.
Code execution.
Computer interaction.
Function calling.
MCP connections.
Tools allow the model to interact with capabilities beyond language generation alone.
The question becomes:
What capability does the model need to accomplish this task?
06 — CONVERSATION
Conversations maintain related input and output items across multiple interactions.
Useful AI work often takes more than one turn.
You ask.
The model responds.
You add information.
The model continues.
The Responses API supports continuing related interactions rather than treating every request as completely isolated.
That enables:
Follow-up questions.
Corrections.
Refinement.
Additional context.
Continuing work.
Conversation turns individual responses into an evolving interaction.
07 — MULTIMODAL
Multimodal capabilities let models process text and images within requests.
Human information does not exist only as text.
Sometimes the model needs to work with an image.
A document.
Or another supported form of information.
Multimodal capabilities allow applications to provide different forms of input to compatible models.
An application might combine:
Instructions.
Text.
Images.
Files.
And other supported inputs.
The interaction becomes richer than text alone.
08 — STREAMING
Streaming delivers response events progressively while model generation continues asynchronously.
Some responses take time.
Applications do not always need to wait until everything is finished.
Streaming allows response events to arrive while generation continues.
That can include:
Text updates.
Tool-related events.
Completion events.
Other response events.
This can make an application feel more responsive.
Instead of:
Wait → Complete response.
You can have:
Generate → Stream → Receive.
09 — STATE
State preserves relevant interaction information across connected model responses automatically.
Many useful AI tasks continue over several responses.
The system therefore needs a way to preserve relevant interaction information.
State allows later responses to build on earlier work.
That can support:
Follow-up questions.
Refinement.
Continuing reasoning.
Tool workflows.
Longer tasks.
Without state, every request risks becoming an isolated interaction.
With state, responses can become connected work.
10 — JUDGMENT
Human judgment determines which generated outputs and actions deserve acceptance.
The Responses API can make applications powerful.
Models can generate.
Reason.
Use tools.
Retrieve information.
And trigger actions.
But capability does not eliminate responsibility.
Humans and organizations still need to determine:
Is the output accurate?
Is the tool appropriate?
Should this action occur?
Does sensitive information require protection?
Should the result be trusted?
Should the workflow continue?
AI generates and acts within configured capabilities.
Humans remain responsible for deciding what should move forward.
The Entire Book in 100 Words
RESPONSES
Responses provides OpenAI's unified interface for building intelligent applications today.
INPUT
Input supplies text, images, files, or other information for processing.
MODEL
Models process supplied inputs and generate useful outputs or actions.
OUTPUT
Output contains generated messages, tool calls, and other response items.
TOOLS
Tools extend models with search, files, code, computers, and MCP.
CONVERSATION
Conversations maintain related input and output items across multiple interactions.
MULTIMODAL
Multimodal capabilities let models process text and images within requests.
STREAMING
Streaming delivers response events progressively while model generation continues asynchronously.
STATE
State preserves relevant interaction information across connected model responses automatically.
JUDGMENT
Human judgment determines which generated outputs and actions deserve acceptance.
The Minimalist Responses API
You do not need to understand everything about the Responses API before you begin using it.
Remember ten things:
Responses.
Input.
Model.
Output.
Tools.
Conversation.
Multimodal.
Streaming.
State.
Judgment.
Everything else can come later.
Start with the input.
Choose the model.
Understand the output.
Add tools when needed.
Continue through conversation.
Use multimodal inputs when useful.
Stream responses when appropriate.
Maintain state across connected work.
Apply human judgment.
Then accomplish something.
One Final Question
The next time you build with the Responses API, don't begin with:
“Which API parameters should I use?”
Begin with:
“What do I want the model to accomplish?”
Then build the response.
Thursday, June 25, 2026
🧠 Three Core Skills Every AI Engineer Must Master
🧠 Three Core Skills Every AI Engineer Must Master
A Structured Path to Building Real-World AI Systems
Think → Ask → Judge → Accomplish
🌍 Introduction: AI Engineering Is Not What Most People Think
When people hear “AI Engineer,” they often imagine someone training massive neural networks or tuning complex mathematical models.
But in reality, modern AI engineering is far more practical.
It is about building intelligent systems that work in the real world—systems that take inputs, process data, call models, use tools, and deliver useful outcomes.
And to do that well, you don’t need hundreds of skills.
You need just three foundational capabilities—deeply developed and tightly integrated.
🧩 Skill 1: Programming + Data Handling (The Execution Layer)
🧠 Why This Skill Matters
At the core of every AI system is a simple truth:
AI does not run on “intelligence” alone—it runs on data pipelines and code execution.
If data is messy, even the best model fails.
If code is unclear, even the smartest system breaks.
This is why programming—especially in Python—is the backbone of AI engineering.
🧠 THINK: How AI Engineers Should See Code
An AI engineer does not think:
“How do I write this function?”
They think:
“How does data flow from input → processing → model → output?”
They see systems, not scripts.
❓ ASK: The Right Engineering Questions
How is data being collected, cleaned, and structured?
Where does the pipeline break under real-world conditions?
How can I automate repetitive data transformations?
How do I integrate APIs, files, and model calls seamlessly?
⚖️ JUDGE: What Good Looks Like
Strong AI engineers:
Treat data as a living system, not static files
Build modular, reusable pipelines
Debug data issues faster than model issues
Weak engineers:
Focus only on syntax
Ignore data quality
Assume models will “fix everything”
🚀 ACCOMPLISH: Practical Mastery
To build this skill, focus on execution:
Build a CSV → cleaning → model input → output pipeline
Create a small automation tool (summarization, tagging, classification)
Practice integrating APIs into workflows
💡 Goal: You should be able to take raw data and turn it into structured intelligence reliably.
🧠 Skill 2: Machine Learning + Model Intuition (The Understanding Layer)
🌍 Why This Skill Matters
AI systems are powered by models—but controlled by understanding.
You don’t need to be a research scientist.
But you must understand:
How models learn, fail, and behave under different conditions.
🧠 THINK: Seeing Beyond the Output
Instead of asking:
“What is the answer?”
You ask:
“Why did the model produce this answer?”
This shift changes everything.
You start seeing patterns like:
Bias in data
Overfitting vs generalization
Feature sensitivity
Training vs inference mismatch
❓ ASK: Diagnostic Thinking
Is this failure caused by data or model limitation?
What changes performance more: features or training data?
Why does performance drop on new inputs?
What assumptions is the model making?
⚖️ JUDGE: Engineering Intuition
Strong AI engineers:
Treat models like systems with constraints
Expect failure modes and design around them
Compare models critically instead of trusting defaults
Weak engineers:
Treat models as black boxes
Accept outputs without validation
Confuse “working demo” with “robust system”
🚀 ACCOMPLISH: Building Intuition
Train simple models (linear regression, decision trees)
Compare performance across datasets
Experiment with feature changes and observe impact
Document model behavior patterns
💡 Goal: You should predict how a model will behave before running it.
⚙️ Skill 3: LLM + AI System Design (The Orchestration Layer)
🌍 Why This Skill Matters
This is where modern AI engineering becomes powerful.
Today, the real value is not in a single model.
It is in systems of models + tools + prompts + memory + logic.
🧠 THINK: Systems Over Models
Instead of thinking:
“How do I prompt this model?”
You think:
“How does this entire AI system behave end-to-end?”
You start designing flows like:
Input → Context → Retrieval → Reasoning → Tool Use → Output
❓ ASK: System-Level Questions
Where should memory live in this system?
When should tools be triggered?
How do I handle uncertainty or failure?
What happens when the model is wrong?
How do I improve reliability, not just output quality?
⚖️ JUDGE: What Strong System Design Looks Like
Strong AI engineers:
Build workflows, not just prompts
Design fallback mechanisms
Combine multiple models and tools intelligently
Optimize for reliability and consistency
Weak engineers:
Over-focus on prompt wording
Ignore system architecture
Assume a better prompt solves everything
🚀 ACCOMPLISH: Real AI Systems
Build systems like:
AI chatbot with memory + retrieval
Document analyzer with summarization + classification
Multi-step agent that uses APIs/tools
Workflow automation system (input → reasoning → action)
💡 Goal: You should be able to design AI systems that behave predictably in real environments.
🔗 How These 3 Skills Connect
These skills are not separate—they form a stack:
| Layer | Skill | Role |
|---|---|---|
| 🧩 Execution | Programming + Data | Moves information |
| 🧠 Understanding | Machine Learning | Interprets intelligence |
| ⚙️ Orchestration | AI System Design | Builds behavior |
When combined:
You stop using AI tools and start building AI systems.
🚀 Final Insight: The Real Definition of an AI Engineer
An AI engineer is not someone who:
Knows every model
Memorizes every algorithm
Follows tutorials
An AI engineer is someone who can:
Turn messy data into structured intelligence
Understand how models behave in reality
Design systems that reliably produce outcomes
That is the real shift.
Not learning more tools—but thinking in systems.
🧠 Try This Challenge
Pick one small idea:
👉 “Summarize meeting notes”
👉 “Classify emails”
👉 “Extract insights from documents”
Then build it using:
Data pipeline (Skill 1)
Simple model or logic (Skill 2)
LLM workflow system (Skill 3)
That’s your first real AI system.
⚡ Key Takeaway
AI engineering is not about building models.
It is about building systems that think, process, and act.
And that starts with mastering just three skills—deeply, not superficially.
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...
