# The AI Agent Framework That Made Me Rethink Everything I Knew About Hardware Controls !(Part 2)

> Source: <https://dev.to/vishalcloud/the-ai-agent-framework-that-made-me-rethink-everything-i-knew-about-hardware-controls-part-2-377l>
> Published: 2026-06-24 17:18:37+00:00

In [Part 1](https://dev.to/vishalcloud/the-ai-agent-framework-that-made-me-rethink-everything-i-knew-about-hardware-controls--25i0-temp-slug-3389044?preview=0ac1a0268adca7353222e29e20182793d73d8978316f8982e17da7c47416e039cc5b62f53c06d1d2c0bb2a6abcb10a4636a2ac21f8bbf7afb990090e), 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.

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?

``` python
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.

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**.

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

**Traditional approach?** You'd need to:

**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.

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.

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

``` php
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.

**Prerequisites:**

**Installation:**

```
pip install strands-ai-functions
```

**Quick Start:**

Build the meeting summarization example from the [README](https://github.com/strands-labs/ai-functions). 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.

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:

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

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.

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

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.

**Option 1: AI Functions (No Hardware Required)**

`strands-labs/ai-functions`

**Option 2: Simulation (No Hardware Required)**

`strands-labs/robots-sim`

`python examples/libero_example.py`

with the mock policy**Strands Robots is your playground:**

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

`robots-sim`

project explicitly calls out If you've been following along with the examples and created AWS resources:

**For AI Functions:**

**For Robots Sim:**

`docker stop <container_id>`

`docker rmi <image_id>`

**For Strands Robots:**

**Your next steps depend on your goals:**

`pip install strands-ai-functions`

and run the meeting summarization example today`strands-labs/robots-sim`

and run the Libero example with the mock policy**Key Resources:**

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!

**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.
