Write Once, Run Anywhere: Universal Tools for AI Agents

Yaala Labs has released Agent Kernel, an open-source library that lets developers write AI agent tools once as plain Python functions and bind them to multiple frameworks, including OpenAI, CrewAI, LangGraph, and Google ADK. The project addresses the duplication problem where the same tool, such as a weather lookup, must be rewritten for each framework's decorator and tool format. A single .bind() call translates the function into each framework's expected format.

By Yaala Labs https://github.com/yaalalabs Stop rewriting the same tools for different AI frameworks. Imagine building a calculator app, then discovering you need to rebuild it from scratch every time you want to run it on a different device. That's what building AI agent tools feels like today. Write a weather lookup tool for OpenAI? It won't work with Google's framework. Build it for CrewAI? Start over if you switch to LangGraph. This wastes time and creates headaches every time you want to try a new AI framework. Agent Kernel solves this: write your tools once, use them everywhere. Think of tools as capabilities you give your AI agent—like looking up weather, searching a database, or sending emails. Right now, each AI framework requires you to write these tools in a completely different way. Here's the same weather tool written for four different frameworks: php OpenAI version @function tool def get weather city: str - str: return f"Weather in {city}: sunny" CrewAI version @tool def get weather city: str - str: return f"Weather in {city}: sunny" LangGraph version @tool def get weather city: str - str: return f"Weather in {city}: sunny" Google ADK version def get weather city: str - str: return f"Weather in {city}: sunny" get weather = FunctionTool get weather It's the same weather lookup, but you have to write and maintain four different versions. Want to switch frameworks? Rewrite everything. Want to try a new framework alongside your current one? Duplicate all your tools. Building 10 custom tools means maintaining 40 versions if you use all four frameworks. With Agent Kernel, you write your tools as regular Python functions—no special decorators or framework-specific code: php def get weather city: str - str: """Returns the weather for a given city.""" return f"Weather in {city}: sunny, 25°C" That's it. Just a normal Python function with a helpful description. Then use it with any framework you want. Once you've written your tool as a normal Python function, you can add it to agents in any framework. The only thing that changes is one line of code: python from agents import Agent from agentkernel.openai import OpenAIToolBuilder weather agent = Agent name="weather", instructions="You provide weather information.", tools=OpenAIToolBuilder.bind get weather , ← Add your tool here python from crewai import Agent from agentkernel.crewai import CrewAIToolBuilder weather agent = Agent role="weather", goal="You provide weather information", backstory="Use the get weather tool for queries.", tools=CrewAIToolBuilder.bind get weather , ← Add your tool here python from langgraph.prebuilt import create react agent from agentkernel.langgraph import LangGraphToolBuilder weather agent = create react agent name="weather", tools=LangGraphToolBuilder.bind get weather , ← Add your tool here model=model, prompt="Use the get weather tool for queries.", python from google.adk.agents import Agent from agentkernel.adk import GoogleADKToolBuilder weather agent = Agent name="weather", model="gemini-2.0-flash-exp", description="You provide weather information", tools=GoogleADKToolBuilder.bind get weather , ← Add your tool here Same get weather function. Works everywhere. The .bind method translates your normal Python function into whatever format each framework needs. You don't have to worry about the details—just write your function once and use it anywhere. Making tools work across frameworks sounds simple, but it's actually quite challenging. Each framework has its own way of handling tools, and these differences create real technical problems. Frameworks handle async/sync functions differently: LangGraph LangChain requires you to specify whether a tool is async or sync upfront: Sync tools use 'func' parameter StructuredTool.from function func=my tool Async tools use 'coroutine' parameter StructuredTool.from function coroutine=my async tool OpenAI Agents SDK automatically handles both, but wraps them differently internally. Google ADK expects all tools to potentially receive a tool context parameter from the framework itself, which other frameworks don't provide. Agent Kernel detects whether your function is async or sync and generates the right code for each framework automatically. You just write def or async def . This is the hardest problem: frameworks provide execution context session info, runtime state in completely different ways. OpenAI, CrewAI, LangGraph work well with Python's standard contextvars , which lets you set context in one place and access it anywhere in the call stack: Set once before calling agent context.set Access anywhere in your tool ctx = ToolContext.get Google ADK manages its own execution context internally and doesn't reliably propagate Python's contextvars . Instead, it passes a tool context parameter to every tool function: python ADK calls your tool like this: def my tool city: str, tool context: ADKToolContext : ADK's context, not yours This means your tool function signature must be different for ADK versus other frameworks. Or does it? Agent Kernel solves this by: tool context parameter automatically ToolContext All this happens behind the scenes. You write one function, and it works everywhere. Each framework expects different information about your tool: | Framework | Name Source | Description Source | Schema Generation | |---|---|---|---| | OpenAI | Function name | Docstring | Automatic from type hints | | CrewAI | Function name | Docstring | Automatic from type hints | | LangGraph | Must specify | Must specify or falls back to function name | Must extract from function | | Google ADK | Function name | Function name if no docstring | Type inspection required | Agent Kernel extracts metadata once from your Python function name, docstring, parameters, types and formats it appropriately for each framework. When a tool raises an exception, frameworks handle it differently: Agent Kernel doesn't hide these differences they're tied to framework behavior , but it ensures your tool code doesn't need to know which framework is calling it. Each framework's tool classes come from different packages: python from agents import function tool OpenAI from crewai tools import tool CrewAI from langchain core.tools import StructuredTool LangGraph from google.adk.tools import FunctionTool Google ADK If you write tools using framework-specific decorators, you're locked in. Agent Kernel's ToolBuilder classes handle these imports internally, so your tool code has zero framework dependencies. Here's what Agent Kernel does behind the scenes for a single tool: ToolContext.get works in your tool All so you can write this: php def my tool param: str - str: """Does something useful.""" return result tools = AnyFrameworkToolBuilder.bind my tool This simplicity is hard-won. Framework-agnostic tools require handling edge cases most developers never see. Sometimes your tools need to know things like "which user is asking?" or "what session is this?" Agent Kernel provides this information in a consistent way, regardless of which framework you're using: php from agentkernel.core import ToolContext def get weather city: str - str: """Returns the weather for a given city.""" Get information about the current execution ctx = ToolContext.get session = ctx.session Who's asking? agent = ctx.agent Which agent is calling this? Example: Use session data for personalization user prefs = session.get non volatile cache .get "preferences", {} units = user prefs.get "temperature units", "celsius" return f"Weather in {city}: sunny, 25°C" This works the same way across all frameworks—you don't need to learn different methods for each one. Here's a complete example using OpenAI: python from agentkernel.core import ToolContext from agentkernel.openai import OpenAIModule, OpenAIToolBuilder from agents import Agent def get weather city: str - str: """Returns the weather for a given city.""" if city == "Tokyo": return "The weather in Tokyo is sunny." else: return f"Cannot find weather for {city}." Create agents weather agent = Agent name="weather", instructions="Use the get weather tool for weather questions.", tools=OpenAIToolBuilder.bind get weather , math agent = Agent name="math", instructions="You help with math problems.", triage agent = Agent name="triage", instructions="Route questions to the right agent.", handoffs= math agent, weather agent , OpenAIModule triage agent, math agent, weather agent Want to try LangGraph instead? Change just the framework-specific parts: python from agentkernel.langgraph import LangGraphModule, LangGraphToolBuilder from langgraph.prebuilt import create react agent Same get weather function - no changes weather agent = create react agent name="weather", tools=LangGraphToolBuilder.bind get weather , Different builder model=ChatOpenAI model="gpt-4o-mini" , prompt="Use the get weather tool for weather questions.", Define other agents... LangGraphModule triage agent, math agent, weather agent Your get weather function? Completely untouched. No rewriting. No debugging. Just works. If your tool needs to do asynchronous work like database queries or API calls , just write it as an async function: php async def search database query: str, limit: int = 10 - str: """Searches the database for matching records.""" results = await db.search query, limit=limit return str results Works with any framework automatically tools = OpenAIToolBuilder.bind search database tools = LangGraphToolBuilder.bind search database tools = GoogleADKToolBuilder.bind search database Agent Kernel handles the async details for you—just write your function normally. Real agents usually need multiple tools. Just add them all to the list: tools = OpenAIToolBuilder.bind get weather, search database, send email, get user profile, agent = Agent name="assistant", instructions="You're a helpful assistant with multiple tools.", tools=tools, All tools work together seamlessly, regardless of your framework. Want to see if LangGraph is better than OpenAI for your use case? Just switch. Your tools keep working. No migration project needed. Test your tools as regular Python functions: python def test get weather : result = get weather "Tokyo" assert "sunny" in result.lower No complicated framework setup. No mocking. Just normal Python testing. Your tools are just functions. Easy to read. Easy to understand. Easy to maintain. No framework magic hiding what your code does. New developers don't need to learn framework-specific tool systems. They write regular Python functions. Everything else is handled automatically. You might have heard of MCP Model Context Protocol and wonder: "Should I use MCP for my tools, or build them locally?" The answer depends on what your tools do. Let's break it down simply: MCP is designed for connecting to external tool servers that run as separate processes. Think of it like calling a web API or external service. Use MCP when: MCP Example: Your Agent → Network → MCP Server → External Database Agent Kernel's tool binding is for tools that are part of your agent's business logic —functions that live in your codebase alongside your agents. Use local tool binding when: Local Tool Example: Your Agent → Direct Function Call → Your Code For most business logic, building tools directly in your agent code is simpler and more efficient: python Local tool - just a function def calculate price quantity: int, item type: str - float: """Calculate price with discounts.""" base price = PRICES item type quantity discount = get bulk discount quantity return base price 1 - discount Use it immediately tools = OpenAIToolBuilder.bind calculate price With MCP, you'd need to: Local tools are just function calls—microseconds. MCP involves network requests—milliseconds or more. For tools that run frequently, this adds up. Local: Direct call, ~microseconds result = calculate price 100, "widget" MCP: Network round-trip, ~10-100ms result = await mcp client.call tool "calculate price", {...} python Test local tools like any Python function def test bulk discount : price = calculate price quantity=100, item type="widget" assert price < calculate price quantity=10, item type="widget" MCP tools require running a server, mocking network calls, etc. When something goes wrong with a local tool, your debugger works normally. Step through your code, inspect variables, see the full stack trace. With MCP, you're debugging across process boundaries and network calls. Much harder. Local tools deploy with your agent—one Docker container, one deployment. MCP tools need separate infrastructure, monitoring, and coordination. Don't get us wrong—MCP is valuable for the right use cases: Shared Corporate Tools: Your company has a central "Employee Directory" service used by 50 different AI agents. One MCP server, everyone connects to it. External Services: You're integrating with a third-party tool provider like a specialized search engine or data enrichment service that offers MCP access. Language Boundaries: Your tool is written in Rust for performance, but your agent is in Python. MCP lets them communicate. Heavy Resources: Your tool needs 64GB of RAM and a GPU. Run it on a dedicated server via MCP instead of bundling it with every agent instance. Start with local tools. They're simpler, faster, and easier to build and test. Only use MCP when you have a specific reason: For most business logic—data formatting, calculations, querying your own databases, calling your internal APIs—local tools are the right choice. Agent Kernel supports both approaches. Use local tools for your custom logic, and connect to MCP servers when you need external capabilities: Local tools for your business logic local tools = OpenAIToolBuilder.bind calculate price, format invoice, check inventory, MCP tools for external services if needed Connect to MCP server for shared document search mcp tools = await connect to mcp server "company-docs" Use both together agent = Agent name="sales assistant", tools=local tools + mcp tools, The key insight: Local tools and MCP serve different purposes. Don't add MCP complexity unless you need it. For most agent development, simple local tools are the better choice. When you write a tool as a normal Python function, Agent Kernel automatically extracts everything the AI needs to know: The AI sees the same tool, no matter which framework you use. Using framework-agnostic tools is simple: pip install agentkernel php def my tool param: str - str: """Description of what this tool does.""" Your code here return result python from agentkernel.openai import OpenAIToolBuilder from agents import Agent agent = Agent name="my agent", instructions="Use my tool when needed.", tools=OpenAIToolBuilder.bind my tool , That's all. Three steps, and your tool works across all frameworks. Stop maintaining multiple versions of the same tool. Write your tools once. Test them once. Use them everywhere. That's the promise of framework-agnostic tools in Agent Kernel. Try different frameworks. Migrate painlessly. Focus on building great tools, not maintaining duplicates. Start building framework-agnostic tools today. Your future self will thank you. Originally published at kernel.yaala.ai https://kernel.yaala.ai/blog/framework-agnostic-tool-binding on February 18, 2026.