Your Tasks, callable from Claude, ChatGPT, or wherever else you work
The Execution MCP Server makes the Tasks you have already built callable as tools from an external MCP client. Your client passes the inputs, the Task runs on Aisle's managed runtime, and the output comes back in the chat window. That includes Claude Code, Cursor, VS Code, claude.ai, ChatGPT, and anything else that speaks MCP.
MCP is a good distribution tool, and a poor runtime. We keep the execution, the credentials, and the logic where they can be versioned, logged, and tested. That leaves you deterministic in execution and agentic in orchestration, which promotes consistency.
A CRM your sales team can talk to
Alex built a CRM out of an Airtable base and one Task with four modes. Mount that Task on an execution server and the sales team works the pipeline in natural language, without edit access to the table. Any other database works the same way.
The Airtable rows change alongside the chat.
The run model
A tool call waits about ten seconds. If the Task finishes inside that window, the output comes back inline. If it does not, you get an execution_id and a suggested poll interval, and the run carries on in the background while your client polls check_task_status and get_task_logs. A Task that takes four minutes never trips a client timeout that fires at one.
In the app it lives under Developers > Execution MCP Server > New Connection.
Two builds and one argument
Building a Lead Gen Automation Prototype. The most-copied lead-gen template on n8n scrapes Google Maps and ends in a spreadsheet. Rebuilt as a Task with native Google Maps, Apollo.io, HubSpot, and Slack, the same job ends in the CRM.
PowerPoint content automation. Mail merge for decks. A PPTX template marked with {{placeholder}} tokens goes in, aisle.powerpoint.fill fills one deck per row of data, and aisle.files.zip bundles the results into a single download.
The Model Is an Input. On Microsoft's latest earnings call, Satya Nadella described the architecture we built Tasks around: keep the harness separate from the model and every model becomes substitutable. Your IP is the code, model choice is a one-line edit per step, and you can price a run before you ship it.
The layer around the model
Three items from the past two weeks, each arguing that the deterministic parts of an agent stack are where the engineering sits.
- Zenity raised $125 million. The Series C, led by Norwest, went to a platform that reads what an agent intends to do and allows, modifies, or blocks it before execution, rather than reviewing logs after the fact. Zenity Labs' own researchers have demonstrated zero-click exploits that hijack multi-step agent workflows.
- Halborn published a report on agents in financial infrastructure. The advice is to treat every input the agent reads as untrusted, have the agent propose rather than execute, and leave the decision to a deterministic policy engine independent of the model. A successful prompt injection then produces a malicious proposal instead of a moved wire.
- Stonebranch was named a Leader in the 2026 Gartner Magic Quadrant for Service Orchestration and Automation Platforms. Third year running, for Universal Automation Center. Read it as incumbent automation infrastructure absorbing agentic workloads while keeping the control plane.
Sources: Zenity · SecurityWeek · Halborn · Stonebranch
Video transcript
Let's build a really simple CRM based on tasks and air table. You could do this with any database, Postgres, Azure, MySQL. I'm going to use Air Table because it lets us see our data right on our demo screen. So, as you can see, I have a list of companies. These are deals that are in progress in our pipeline.
Each has a value, a stage, an owner, and for those that were lost, we have a reason. Here's what our task looks like. The important part is down here. We have this main dispatcher method called CRM. And it has different modes.
It is a show mode, an open mode, pitched one, and lost for updating existing deals. These are the actions that I can take on the deals. And we're going to expose these in a chat so that someone on a sales team can interact with them using a chat. So I've mounted this tool on an MCP server using IS and I've configured it in a cloud project. So in this project I can actually just start interacting with this tool by chatting with natural language.
I can say what's in my CRM. It's going to access my server. It's going to pull the tools and it's going to query it for the data. All right, here it is. So this should match the data that we saw in the air table.
Let's go ahead and create a new deal. I want to create a new deal. Uh the company is Alliant. It's 42K and Marcus is the owner. So, it's going to access my tools and it's going to call that open tool to create a new row in our air table.
Let's go back and check our air table. Indeed, here is that alliant row Marcus 42,000. It's initialized into the lead state. Okay. Uh so let's update it and say actually that deal has been pitched again.
It's going to call my tool. It's now pitched again. We snap back to our air table. It is pitched. So, let's say unfortunately Marcus lost the deal because he was late from lunch.
So it understands that it's going to write to our air table and it confirms and we say yes that is the reason recorded again. Let's check our air table. There it is. Mark it was late from lunch. So this basically lets us give the users access to this database to make changes to it but in a safe way.
We're not giving them cartel launch access to the table. They can't come in and just edit anything. They must use the tools and those tools we're exposing in this case in a clawed chat. You could also use these tools from projects within Aisle. You could use this in chat GPT.
Uh because they are published or exposed on an MCP server, you could even bring them into cloud code and use them locally.