The Slack message came in at 11pm on a Wednesday from a client who had watched me build an OpenAI function-calling workflow three weeks earlier and had since decided, without telling me, to extend it himself. The message was a screenshot of an error: Cannot read properties of undefined (reading choices) thrown from a Code node that was trying to parse a response that had not arrived in the shape he expected. Below the screenshot: I just added a second AI step, is this a n8n thing or an OpenAI thing? It was neither. It was an orchestration thing. And explaining why required explaining something that most AI tool coverage has been carefully avoiding for about eighteen months.
The Berlin startup is called Composio. If you have not heard of it, that is consistent with how infrastructure companies tend to exist — invisibly, until they are everywhere. What they have built is a managed tool and integration layer designed specifically to sit between large language models and the external systems those models need to act on. Authentication handling, schema normalisation, API versioning, retry logic, error surfaces that the model can actually interpret and respond to rather than fail silently against. The unglamorous connective tissue that makes agentic AI workflows not collapse on the third step.
I want to explain why this matters from where I am sitting, which is inside n8n workflows that are trying to give language models access to real systems, because the gap between what the demos show and what production actually requires is where most of this work lives.
When I built the invoice approval flow for a client last year, the architecture looked simple in the planning conversation: an OpenAI model reads the invoice, extracts the relevant fields, checks them against approval rules, and either routes for payment or flags for human review. Two AI steps, some conditional logic, done. The reality was that the OpenAI function-calling response came back in a structure that changed slightly depending on whether the model decided to call a function or just respond with text, which meant the Code node downstream needed to handle both cases, and the n8n documentation on parsing function-calling responses showed the happy path only. When the model returned a text response instead of a function call because the invoice was ambiguous, the workflow threw an undefined error on the choices[0].message.function_call property and stopped. I caught this in testing. Barely.
That specific failure mode, where an AI component in a workflow returns a structurally different output than expected and every downstream node breaks, is not an n8n problem or an OpenAI problem. It is an orchestration problem. The model is doing what models do, which is produce variable output based on variable input, and the workflow is doing what rigid pipelines do, which is assume the shape of the next input will match the shape of the last output. The mismatch is architectural.
What Composio is solving is that the tools an agent can call need to be wrapped in something that normalises the interface, handles authentication state, manages the back-and-forth when an API returns a 429 or a shape the model did not expect, and surfaces errors in a form the model can reason about rather than a form that just breaks the pipeline. OpenAI’s plugin architecture tried to do some of this and was quietly folded into the assistants API. Google’s approach with their agent tooling is more complete but tightly coupled to their own model ecosystem. Composio’s position is model-agnostic, which is either a genuine architectural advantage or a go-to-market strategy, and right now it looks like both.
I have not run Composio in production. I want to be direct about that. I have tested their tool execution layer against a workflow I was already running in n8n using HTTP Request nodes to call external APIs manually, and the comparison is instructive. My HTTP Request implementation handles the authentication, constructs the request, parses the response, and routes errors to a Slack notification. That is four nodes and a Code node and a Set node and about two hours of testing. The Composio equivalent is one configured tool call with error handling built into the layer below where I am working. The reduction in surface area is real.
The part that interests me most is what this means for building agentic workflows in n8n specifically, because n8n is where I live and the gap between what n8n can do natively with AI Agent nodes and what actually holds together under production conditions is significant. The AI Agent node is genuinely useful. It is also, in its current form, a thin wrapper around a model API with tool definitions that you configure manually and error handling that you are responsible for entirely. Composio sitting underneath that layer would mean the tools the agent can call are pre-normalised, pre-authenticated, and pre-wrapped in error handling that the model can interpret. That is a different class of reliability.
LangChain tried to be this and became something else. It accumulated abstractions until the thing you were debugging was not your workflow logic but LangChain’s internal state management, and the version-to-version breaking changes made production maintenance a genuine problem. I moved two projects off LangChain in the last year and both migrations were longer than they should have been because the documentation had not kept up with what the library was actually doing.
Composio is not trying to be a framework. It is trying to be infrastructure. That distinction, if they hold it, is the entire bet.
The client who messaged me at 11pm eventually fixed his workflow by adding a conditional check before the Code node that handled both possible response shapes. It took him forty minutes. It would have taken him four minutes if the tool layer he was calling through had told the model, in terms the model could act on, that the invoice structure was ambiguous and a structured response was required. The problem was not in the workflow. The problem was in the gap between the model and the system it was trying to act on.
That gap is what Composio is selling. The fact that nobody has solved it cleanly yet is why the sale is worth watching.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.
