The AI Agent Framework That Made Me Rethink Everything I Knew About Hardware Controls !(Part 2) Strands Labs released AI Functions, a framework that lets developers write Python functions by describing their behavior in plain English, with runtime validation to ensure correctness. The framework uses Amazon Bedrock to generate implementations and automatically retries if post-conditions fail, enabling reliable AI-powered code generation. A practical example shows loading invoice data from multiple formats using the same function. 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