I’m a Product and Operations minded person with a background in low-code automation tools like Tray.io and Workato. I’ve recently been fascinated by the potential of AI-Agent-driven workflows. I’ve been thinking about this for two different purposes:

1. For powering AI native Products with Agent functionality for external customers. I also see this as learning an aspect of the technology that is predicted to disrupt some of our current SaaS tools.

2. For automating back of the house business workflows that could make any business more efficient.

Recently, I’ve set out to get my hands dirty with a new challenge: building an Agent setup that combines the Model Context Protocol (MCP) and n8n, a popular open-source workflow automation platform. Here’s how I approached it, what I learned, and why this AI Agent approach could likely satisfy some product functionality or business automation needs.

Why MCP and n8n?

Before diving into the setup, let’s define the key concepts:

• n8n: An open-source platform for building workflows, often hailed as a go-to standard for low-code AI Agent automation. I like that you can bypass paying for it as a SaaS tool if you self-host it yourself (you still have the hosting fees though!). The community support for it is also quite large at the moment.

• Model Context Protocol (MCP): Developed by Anthropic, MCP is an open-source protocol that allows AI systems (like Claude, ChatGPT, or others) to securely connect to external data sources, tools, and prompts via a client-server architecture. It is sort of like a universal API for AI Agents. (Learn more: Anthropic’s announcement and MCP’s intro).

Together, they seemed like a great combo for learning some functional aspects of AI Agents.

Setting It Up

Here’s how I got started:

1. Self-Hosting n8n:
   To unlock the full potential of this setup, you need to self-host n8n. Why? Because the magic happens with a community “node” (or workflow step) that isn’t available in the cloud version. I used Elest.io for hosting because the setup was easy for n8n. That said, you could opt for Digital Ocean, Hostinger, or any provider that suits your technical comfort level. These other options will most likely be cheaper to host as well.

2. Installing the MCP Community Node:
   To bring MCP into n8n, I installed the community node from nerding-io/n8n-nodes-mcp. This node acts as the bridge between n8n workflows and MCP-compatible tools. Without it, you’re only able to use the standard n8n node functionality.

3. MCP Tool Compatibility:
   MCP isn’t a free-for-all yet. It only works with tools that have MCP servers implemented. You can check the current list here: modelcontextprotocol/servers.

The Build

The build itself included the following workflow components:

The initial trigger:
The workflow starts when a chat message is received, prompting the LLM-powered Agent to act.

AI Agent node:
The AI Agent node in n8n is the central hub that manages:

• The LLM Model: This powers the agent’s conversational ability. I used ChatGPT.

• The Memory (Simple Memory Database): This keeps track of past interactions for context-aware LLM responses.

• The Tools: This is where the MCP connections were.

MCP List Tools (Brave Search):
This node lets the agent discover available MCP tools. In this example, it’s the Brave Search tool for web queries. This is one of the unique aspects of MCP as opposed to other agent-building approaches. The tool makers can tell the LLMs powering an Agent which functionality is available.

MCP Execute Tool (Brave Search):
Once identified, this node enables the agent to run a Brave Search query and return results to the user.

How It Works

A chat message triggers the AI Agent node, which processes the input using the OpenAI model and memory for context. If needed, it calls Brave Search to list tool options or execute a search. It then responds back to the user. This is all within a compact workflow.

Key Lessons from the Build

As I pieced this together, a few insights stood out:

• Prompting Is Critical:
  When setting up the Agent Node in n8n, it is extremely helpful to include a system prompt instructing it to use tools. Skip this, and your workflow will ping-pong inefficiently, wasting time and resources. A clear prompt is your guardrail to this. This is also just good standard advice anytime you are developing an Agent step utilizing LLMs.

• MCP’s Potential as the “API” for AI Agents:
  Official MCP integrations are still limited, but its design feels like the most likely future. For product managers, operations, or anyone building AI-driven solutions, learning MCP now could provide an advantage. It’s poised to become a universal standard for agent-tool interactions.

• Caveat: Tool Provider Dependency:
  Here’s the catch; MCP’s functionality hinges on the tool providers maintaining their servers. If a provider updates or breaks something, those changes flow straight into your workflow. It’s a double-edged sword: provider managed updates, but less control for you. This may become a consideration in the same way that package dependencies plague development teams. I wouldn’t be surprised to see a whole application security sub-discipline arise from this as well.

Why This Matters

What excites me most about this setup is the promise of its flexibility in the future. With MCP, my Agent can tap into a growing ecosystem of tools without reinventing the wheel for each integration. Pair that with n8n’s workflow builder, and you’ve got a low-code playground for experimenting with AI agents. I’ll be honest though, it was definitely still a little clunky since I implemented this with a newly developed community package in n8n that’s not yet natively supported. Limited tool options on the third-party MCP servers is also a hurdle at the moment.

For anyone curious about the intersection of AI and automation, MCP is definitely worth a look. It might make sense to hold off on implementing it within n8n for a little bit though if you’re looking to build a production workflow, since the support is rapidly evolving. I would definitely recommend testing playing around with it in n8n or another workflow in order to learn the ropes though.

Thanks for reading!

OpenAI recently released its new Responses API, and I decided to test its capabilities by building something useful for my kids' local soccer league; a chatbot for parents, coaches, and referees. This was a really fun project for me to get my hands dirty with the new api, build a chat agent, and implement real-time web search into it.

The Setup

With OpenAI's new API, getting up and running was relatively straightforward. I initially outlined my vision in a Product Requirements Document (PRD) to keep myself focused and then worked up some boiler-plate python chat agent code by going back and forth between Grok and Claude. I then integrated the Responses API and paired my chatbot with a pdf document of the local soccer league regulations in order to handle common very specific league-related questions.

I really liked how easy it was to pair the Responses API with the OpenAI built-in agent tools.

Supercharging It with Web Search

To take things a step further, I also leveraged OpenAI’s Web Search agent tool. This allowed the chatbot to provide up-to-date league information, like:

• If a field is closed due to weather

• The current prices and purchasing links for recommended equipment

By combining Responses API + Web Search, the chatbot became more than just a static FAQ bot, it could dynamically fetch relevant updates without requiring manual maintenance.

Some of the relevant API code:

# Initialize the OpenAI client with the API key from environment variables

client = OpenAI(api_key=os.getenv('OPENAI_API_KEY'))

# Responses API code

response = client.responses.create(

model="gpt-4o",

tools=[{"type": "web_search_preview"}],

input=user_input,

instructions=system_prompt

)

Key Takeaways

Overall, the project was relatively easy, and this seems like the start of many more built-in agent tools by the major AI platforms. I also can’t state enough how important it was to start with a PRD if you’re looking for the best result with some AI generated code. That helped me out a great deal during the Grok and Claude portions of my workflow.

I would love to hear what others are building with these APIs. Drop a comment or reply if you want to share.

Key Links

• My GitHub repository for this project

• OpenAI’s blog post on new Agent tools

• OpenAI’s Responses API documentation

• OpenAI’s Web Search documentation

This moment in time is generating an underlying level of anxiety for many organizations who have otherwise great Product Managers, but that might be slow to adapt to an entirely new way of operating or are uninterested in “learning a little bit of code” to check the work of a GenAI tool. All of the recent posts and talks about the inevitable need for Product Managers to adapt, fail to consider that a non-insignificant percentage of PM’s will not adapt quickly in many organizations. I’d like to make an argument that we “don’t have to throw the baby out with the bathwater” and there may be a way to work with the talents and interests of all types of PM’s.

There is another role in many organizations that is also having an inflection point at the moment, the role of Product Operations. Many organizations started establishing Product Operations teams in the past couple of years, only to later disband their Product Operations team because they were considered a “nice to have”. The age of ubiquitous GenAI provides a catalyst to evolve the role of the Product Operations Manager.

Product Operations Managers tend to land somewhere on the gradient between those whose strengths and interests are more focused on “process and cross-functional collaboration” and those whose are more focused on “analytics and product tools”. Either type could gravitate towards a successful adoption of AI tools, but the latter camp may have an advantage if they are faster to adopt new tools. Product Operations Managers are already in a great position within the product organization to help accelerate bringing a product to market with GenAI. They support product development in a 1:many fashion, they are (usually) the admin for technical product focused tools, and some “can write a little code”. One productive AI-using Product Operations Manager could potentially accelerate multiple Product Managers through acting as a GenAI tool “coach” and/or by partnering with them and using GenAI for MVP creation.

The discovery process, speaking with customers, and deeply understanding the customer problem should always live with the Product Manager. What if, after a PM has a list of acceptance criteria to solve customer problems, they pass that to a Product Ops person instead of an engineer to come up with multiple versions of a product MVP while using GenAI tools? That workflow may make sense in some organizations, and it’s keeping Product Operations in the Operations business. The place Product Operations Managers love to be in.

This has been a thought exercise and the truth is that it is too soon to say how the typical division of duties will shake out in order to bring a product to market. Everyone will have to do what works best for their organization. With the increasing GenAI involvement in product development, there is no better time to encourage your team to learn new skills and for you to evolve as well.

Hi Friends,

This is my first post on this platform and I wanted to give a little bit of an explanation as to why I’ve decided to begin blogging.

1. There are not enough resources focused on the specific topics of Product Analytics and Product Operations.

2. After 6+ years of listening to and troubleshooting for Product teams on these topics, I’ve learned a few things that might benefit others.

3. These topics are universally important for technology companies, or really for any company that has any kind of software at all, and we can’t afford to not get better at these things. Getting better = better software.

Anyway! Thanks for joining me on this journey, it’s all going to be ok.