For me, the watsonx Orchestrate Hackathon October 2025 was less an opportunity to compete in the agentic competition than an opportunity to be sure creating agents in Orchestrate is doable and that I can rely on this offering when proposing projects.
watsonx in the IBM Cloud can be daunting. It's a many-layered offering. Understanding what its legions of named verticals do and how they do it takes research through IBM documentation, (complete, as always, and disjoint, as always). Surprises and footguns abound. But watsonx works and Orchestrate works and in the end it all makes sense and one can see why it is the way is: the IBM approach is, was, and always will be to lay out a complete set of building blocks so that any business case is accommodated, not just the fad of the moment. Blue and ponderous but all-encompassing, IBM is as much a way as an enterprise.
I was able to code an MCP server and chatbot agent and deploy it as a proof of concept. It will take less time next time. MCP is really quite easy in Orchestrate.
My MCP implementation leveraged APIs from a personal website. The APIs query a MongoDB database and return JSON descriptions of sale items. The MCP is only a wrapper around my API calls to which the chatbot agent passes sought items as arguments. To my delight, I did not have to explain the meanings of the fields returned in JSON to my agent: the fields being named things like "name", "description", and "price", the agent was able to describe sale items it fetched without explicit prompting in that regard.
That was a small revelation: I did expect that. The more significant revelation was more subtle. Here let us digress.
- In the 1980's when I learned Smalltalk, I was baffled until a support person explained to me, "You're thinking procedurally, but this is an object language."
- In the 2010's when I joined Qiskit, when you logged into Qiskit Slack it would always show a quote from Dr. Jay Gambetta, "You're still thinking too classically."
Something similar occurred to me whilst coding the chatbot agent. Yes, I was surprised by the reasoning inherent in the model (e.g., interpreting the JSON from the APIs), but the bigger surprise was the reasoning that emerged as the chat session context grew richer. That is, once a selection of products had been fetched into the chatbot session, the agent was ready to respond to queries to which the APIs themselves did not explicitly provide answers by the agent's examining the information already received from those APIs in response to previous user prompts.
Satori. Epiphany. I had been thinking like a programmer instead of like a robopsychologist.
Footnote: API calls were an exercise, but the real production way to architect this solution would be to use a vector database, allowing for richer intuitions on the part of the agent from the first query.