The AI Agent Framework - AI Functions and Practical Implementation Strategies !(Part 2)

Part 2: AI Functions and Practical Implementation Strategies

---

What You'll Learn

In Part 1, we explored how Strands Labs enables natural language control of physical robots and simulation environments. In Part 2, we'll dive into AI Functions — the most underrated project in the Strands Labs launch — and provide practical implementation strategies for all three projects.

By the end of this post, you'll understand how to build reliable AI-powered Python functions with runtime validation, and you'll have a clear roadmap for getting started with Strands Labs based on your experience level.

---

Project 3: AI Functions — The One That Quietly Changes Everything

I saved this one for last because I think it's the most underrated of the three, and the one that will have the broadest impact on everyday developers.

The pitch: What if you could write a Python function by describing what it should do in plain English, and let an AI agent generate the implementation — with runtime validation to ensure it actually works?

The Core Concept

from ai_functions import ai_function
from pandas import DataFrame, api

def check_invoice_dataframe(df: DataFrame):
    """Post-condition: validate DataFrame structure."""
    assert {'product_name', 'quantity', 'price', 'purchase_date'}.issubset(df.columns)
    assert api.types.is_integer_dtype(df['quantity']), "quantity must be an integer"
    assert api.types.is_float_dtype(df['price']), "price must be a float"
    assert api.types.is_datetime64_any_dtype(df['purchase_date']), "purchase_date must be a datetime64"

@ai_function(
    code_execution_mode="local",
    code_executor_additional_imports=["pandas.*", "sqlite3", "json"],
    post_conditions=[check_invoice_dataframe],
)
def import_invoice(path: str) -> DataFrame:
    """
    The file `{path}` contains purchase logs. Extract them in a DataFrame with columns:
    - product_name (str)
    - quantity (int)
    - price (float)
    - purchase_date (datetime)
    """

Notice what's happening here. The function body is empty. The docstring is the implementation specification. The check_invoice_dataframe function is the post-condition — it defines what "correct" looks like. If the AI-generated implementation fails the post-condition, the framework automatically retries with the error context.

A Different Mental Model

This is a fundamentally different mental model for working with LLMs in code. Instead of prompt engineering your way to correctness, you're writing tests first and letting the framework handle the implementation. If you've ever done Test-Driven Development (TDD), this will feel familiar — except the "developer" writing the implementation is an AI agent powered by Amazon Bedrock.

Real-World Example: Unknown File Formats

The practical example that sold me: loading invoice data from files in unknown formats.

Traditional approach? You'd need to:

• Detect the file format
• Write transformation logic for each format
• Handle edge cases
• Parse LLM responses
• Orchestrate retries
• Dozens of lines of code

With AI Functions:

# Load a JSON file
df = import_invoice('data/invoice.json')

# Load a SQLite database — same function, different format
df = import_invoice('data/invoice.sqlite3')

# Fuzzy merge product name variants
df = fuzzy_merge_products(df)

The same function handles both. The agent inspects the file, determines the format, generates the appropriate parsing code, validates the output against your post-conditions, and retries if anything fails.

Solving the Trust Gap

One of the biggest objections I hear from developers in my workshops about using LLMs in production workflows is: "How do I know it did the right thing?"

AI Functions addresses this directly. You're not trusting the LLM to be correct — you're trusting your own post-conditions to catch when it isn't. The LLM is a code generator; your assertions are the safety net.

Async Multi-Agent Workflows

The library also supports async multi-agent workflows, which opens up some genuinely powerful patterns:

async def research_stock(stock: str) -> StockInfo:
    # Run news research and price fetching in parallel
    news, prices = await asyncio.gather(
        research_news(stock), 
        research_price(stock)
    )
    return StockInfo(stock, news, prices)

Each of those functions is an @ai_function. You're composing AI agents the same way you'd compose regular Python functions. Async, parallel, type-safe.

Getting Started

Prerequisites:

• Python 3.12+ (3.14+ recommended)
• Valid credentials for supported model providers (AWS Bedrock, OpenAI)
• AWS account with Bedrock access

Installation:

pip install strands-ai-functions

Quick Start:
Build the meeting summarization example from the README. It's a clean, self-contained demo that shows the post-condition validation loop in action.

Next Step:
Think about a data transformation problem you've been putting off because it's too tedious to write — and try expressing it as an AI Function.

---

The Bigger Picture: Why Strands Labs Matters

Let me step back from the code for a moment and talk about what this organization represents — not just technically, but architecturally.

AWS made a deliberate choice to separate Strands Labs from the main Strands SDK. This isn't just organizational hygiene. It's a statement about how they want to develop at the frontier: fast, experimental, community-driven, without the weight of production release cycles.

Every project ships with:

• Clear use cases
• Functional code
• Tests
• Documentation

You're not getting half-baked demos — you're getting experiments that are ready to be built upon.

My Perspective as a Developer Advocate

For those of us in developer advocacy, this is the kind of thing that makes our job genuinely exciting. I've spent the last several months running workshops on building AI agents with Amazon Bedrock and Strands across the APJC region. The questions I get most often are: "What's next? Where is this going? Can agents really do X?"

Strands Labs is AWS's answer to those questions — not in a roadmap slide, but in working code.

And personally? Every time I see a developer's face light up when something they built actually works — when the agent responds intelligently, when the simulation completes successfully, when the robot arm moves exactly as instructed — I think back to that DeepRacer car navigating my living room track. That feeling of "I built this, and it's doing something real in the world" is what we're trying to give every developer who picks up these tools.

---

Getting Started: Your Roadmap

Here's my honest recommendation based on where you are:

If You're New to Strands Agents

Start with the main Strands SDK first. Get comfortable with the model-driven approach. Build a simple agent with a tool or two. Then come back to Strands Labs.

If You're Comfortable with Strands and Want to Explore

Option 1: AI Functions (No Hardware Required)

1. Clone strands-labs/ai-functions
2. Run the meeting summarization example
3. Build your own AI function for a real data transformation problem

Option 2: Simulation (No Hardware Required)

1. Clone strands-labs/robots-sim
2. Run python examples/libero_example.py with the mock policy
3. Watch the agent complete a task in simulation
4. Swap in GR00T when you're ready to go deeper

If You Have Robotics Hardware or Access to a GPU Cluster

Strands Robots is your playground:

1. Set up your SO-101 arm and Jetson device
2. Follow the quick start guide
3. Set up the GR00T inference service
4. Run the complete workflow example
5. Start experimenting with your own natural language instructions

If You Want to Contribute

All three repos are Apache-2.0 licensed and actively accepting issues and pull requests:

• The robots-sim project explicitly calls out ACT and SmolVLA as policy providers that need implementation
• If you have experience with either, that's a concrete contribution waiting to happen
• Documentation improvements, bug fixes, and new examples are always welcome

---

Cleanup

If you've been following along with the examples and created AWS resources:

For AI Functions:

• No cleanup required if using local execution mode
• If using AWS Bedrock, ensure you're aware of model invocation costs

For Robots Sim:

• Stop Docker containers: docker stop <container_id>
• Remove Docker images if no longer needed: docker rmi <image_id>

For Strands Robots:

• Power down robotic hardware safely
• Disconnect cameras and serial connections
• Stop GR00T inference services

---

Take Action Now

Your next steps depend on your goals:

1. Want to experiment without hardware? Start with AI Functions — pip install strands-ai-functions and run the meeting summarization example today
2. Want to see robots in action? Clone strands-labs/robots-sim and run the Libero example with the mock policy
3. Ready to build something real? Pick a data transformation problem you've been avoiding and express it as an AI Function
4. Want to contribute? Browse the open issues across all three repos and find something that matches your expertise

Key Resources:

• Strands Labs Announcement blog
• Strands Labs GitHub Organization
• AI Functions Repository
• Strands Robots Repository
• Strands Robots Sim Repository
• AWS Strands Agents SDK
• Amazon Bedrock
• AWS DeepRacer

---

A Personal Note

From a DeepRacer car crashing into my bookshelf to AI agents controlling robotic arms with a single line of natural language — the distance between those two moments is only a few years, but the leap in what's possible feels enormous.

The tools have gotten dramatically simpler. The capabilities have gotten dramatically more powerful. And the community building on top of them has never been more energized.

Strands Labs is the next chapter. Go build something. Break something. File an issue. The repos are live, the code works, and the community is just getting started.

Hope to see you at the next workshop, where we'll be exploring these tools hands-on together soon!

---

About the Author

Vishal is an AWS Developer Advocate based in the APJC region, where he empowers developers through hands-on workshops, technical content creation, and speaking engagements. He helps developers build AI agents with Amazon Bedrock and Strands, while actively contributing to developer communities through conferences, meetups and technical sessions across the region. When he's not crashing DeepRacer cars into furniture, he's exploring innovative applications of AI in cloud security, DevOps and robotics.

Disclaimer: All thoughts and opinions expressed in this blog series are my own and do not represent the views of AWS or Amazon.

Comments

[Nazar Boyko]

Writing the post-condition first and letting the agent fill the body is a genuinely clean idea, and the TDD analogy fits. The gap I'd name is that check_invoice_dataframe validates the shape, that the columns exist, that quantity is an int, that price is a float, but not that the right values landed in the right columns. A generated parser could read the wrong field into price and still sail through is_float_dtype, so the safety net catches structural mistakes and waves the semantic ones right past. Does the framework regenerate the implementation on every call, or cache it after the first pass? Because if it caches, the post-condition only ever saw the files present at generation time, and a new layout could pass every assertion while parsing wrongly.

[Vishal Alhat]

Hey Nazar, really appreciate you diving into this — both points are sharp and worth addressing.

On the semantic gap — you're absolutely right that is_float_dtype doesn't know whether price actually contains prices or accidentally got quantity values cast to float. The post-condition I showed in the post is intentionally minimal to keep the example readable, but in practice you'd want to layer in semantic assertions too. Something like:

assert df['price'].gt(0).all(), "prices must be positive"
assert df['quantity'].apply(lambda x: x == int(x)).all(), "quantities must be whole numbers"
assert df['purchase_date'].between('2000-01-01', pd.Timestamp.now()).all(), "dates must be reasonable"
Or even a spot-check against known values from a sample row if you have ground truth. The framework doesn't limit what you put in your post-conditions — you can make them as semantically rich as your confidence requirements demand. The example in the post catches structural drift; production code should absolutely go deeper. it's on developers how they define it!

[Vishal Alhat]

On caching vs. regeneration — the framework regenerates the implementation on every invocation. It doesn't cache the generated code between calls. Each time import_invoice is called, the agent inspects the actual file at that path, reasons about its format, generates parsing code, executes it, and validates the output against your post-conditions. So if you pass it a JSON file first and a SQLite database second, it generates different implementations for each.

This means a new layout doesn't silently sneak past — the agent sees the actual file contents each time and generates accordingly. The tradeoff is latency (you're paying for an LLM call per invocation), but the upside is exactly what you're concerned about: it adapts to whatever it encounters rather than relying on stale assumptions from a previous run.

Great questions, Thanks for engaging with this!