Share
Chris Chapman, June 15, 2026
Get the Best Solution
for Your Business Today!
When I talk to analytics teams about AI agents right now, most of the conversation is still in the experimentation phase. IBM’s out-of-the-box solutions are just hitting the market, and a lot of clients are watching to see how those perform before they commit. That’s a reasonable position. But what I notice is that teams running TM1 often don’t realize they’re already sitting on the foundation that makes agent integration actually work. The REST API has been there for years. Programmatic access to TM1 is a very well traveled road.
AWS Bedrock AgentCore’s new managed harness changes the build equation in concrete ways for teams that are ready to move. Here’s how I’m thinking about it.
Table of Contents
TM1’s REST API Is Built for This
The reason TM1 is such a natural fit for agent integration isn’t about any new capability, it’s about maturity. The TM1 API is well-documented and extensively used, and there’s a lot of existing logic and existing patterns to build on. That means when you’re standing up an MCP (Model Context Protocol) layer to connect an agent to your TM1 environment, you’re not starting from scratch on the integration work.
At PMsquare, we’ve built a purpose-built MCP server to run against Planning Analytics, and we chose that architecture because it’s the most efficient way to perform those interactions for an agent. The MCP layer houses all of the API calls in one place. The model interacts with MCP, and MCP handles the heavy lifting of executing the actual TM1 API calls. Once that layer is in place, the sky is sort of the limit. You can do almost anything conversationally that you’d do in the application itself, from loading data to running TI processes to querying cube values across any combination of dimensions.
Cognos Analytics is a different story. Its REST API is mostly around administration of the Cognos environment rather than generating new analytics content. So the pure MCP path is more limited there. But for TM1 shops, the infrastructure story is genuinely strong.
The Part AgentCore Solves That Most Frameworks Don’t
When AWS announced AgentCore, the feature that jumped out at me immediately was built-in memory. This is the real gap in most agent systems today, and it’s the one that kills adoption faster than any technical limitation.
If you’ve used AI tools with any regularity, the pattern is familiar: you have to remind it of something you told it yesterday. You re-establish context every session. And if you’re always having to reprompt and re-educate an agent, that really takes away from the cost savings or the time savings the agent is supposed to provide. Users stop seeing it as a time saver and start seeing it as a new kind of overhead.
AgentCore’s built-in memory means the agent can learn a specific workflow, understand a specific business’s data patterns, and actually get more useful over time. That’s the compound value proposition that doesn’t exist when every session starts at zero.
Memory systems are also genuinely difficult to build. There’s no solved form factor: vector stores, S3-based wikis, hybrid approaches all have different tradeoffs and each requires real testing and evaluation before you can trust it. The fact that AgentCore ships with a working memory architecture eliminates what would otherwise be a multi-sprint detour before you even get to the analytics problem you’re actually trying to solve.
Monitoring is the other thing. At PMsquare, across every agent project we’ve run, monitoring has had to be bootstrapped from the ground up. We assemble open monitoring solutions just to get the visibility we need: what is the agent doing, when are feedback loops going wrong, how do we intervene. AgentCore has observability built in through OpenTelemetry. That’s typical AWS: they identify the undifferentiated work and lift it for you.
The Work That’s Still on You: Your Knowledge Base
Here’s where a lot of teams will stumble even with good infrastructure.
For an agent to reliably query a TM1 environment, it needs to know that environment specifically. Which cubes exist, what dimensions they contain, what the aliases are. If that documentation isn’t baked into the agent’s memory system before it starts handling real queries, the model will spend enormous time and tokens reverse-engineering the entire TM1 server on its own.
Think about what happens when a user asks for revenue by state for 2024. There may be a dedicated revenue cube. There’s also an income statement. There could be several other cubes with dimension names that sound plausible. The agent has to interrogate all of them to find the right one unless it already knows exactly which cube to go to. That’s not a model limitation. That’s a documentation problem.
This knowledge base work is fundamental to making the system perform well. You can partially automate it by querying the TM1 server directly for cube and dimension structure, but the business context layer, deciding how to describe what a given cube actually represents in terms a model can reason with, is inherently manual. Budget real time for this work before you go live with anything user-facing. It pays back.
Using Agents for Monitoring, Not Just Queries
Most of the conversation about analytics agents focuses on the query side: users asking business questions and getting answers. There’s another category that I think is underappreciated, and that’s using agents to manage and monitor the Cognos environment itself.
Right now, most Cognos monitoring is purely threshold based. A metric crosses a line, an alert fires. What an agent changes is the reasoning layer. Instead of firing on a single KPI, an agent can look at performance information from the server, cross-reference it with Cognos logs, factor in query load patterns, and arrive at a more precise decision about whether something actually needs attention. The corrective actions become more adaptive to a broader range of metrics and the health of the environment as a whole.
We’re building toward this at PMsquare. The design pattern is clear, an MCP server for Cognos administration is a realistic architecture given what the API supports, and we’ve done enough foundational agent work to know how it fits together. We’re not running this in production for clients today, but that’s the direction.
Where to Start
If I’m talking to an analytics director who wants something real in production this year, my advice is: start with TM1, start with a use case that has clear success criteria, and do the knowledge base documentation work before anything else goes live. Don’t wait for IBM’s out-of-the-box agent solutions to fully mature. The REST API you already have, combined with AgentCore’s managed infrastructure, is enough to build something that genuinely saves people time.
The platforms that have had mature programmatic APIs for a long time are the ones where agent integration has the clearest path right now. TM1 is that platform. The infrastructure gap just got smaller.
Questions I’m Hearing From Clients
How long does documenting a TM1 environment for agent use actually take?
For a mid-size TM1 deployment, I’d plan for weeks of focused effort, not days. You can automate part of it by querying the server directly for cube and dimension structure, but the business context work, describing what each cube actually represents in terms an agent can use to make routing decisions, requires someone who knows the environment. The upfront investment is real, but it’s what makes the difference between an agent that guesses and wastes tokens and one that answers accurately the first time.
For teams primarily on Cognos Analytics without a TM1 footprint, is there still a path?
Yes. The Cognos REST API is limited on the analytics generation side, but there’s also the underlying Cognos SDK, which opens up a lot of possibilities. You can build a middleware piece and connect it to a custom-developed front end. We’ve done that and seen good results. It’s more custom work than the TM1 MCP path, but it’s not a dead end. And for teams looking at the monitoring and administration use case, the Cognos REST API is more sufficient.
Is ContextForge from IBM production-ready today?
Honestly, ContextForge is very new. We like what it brings to the table, especially the governance and observability layer on top of MCP that plain MCP doesn’t provide on its own. But we don’t have a lot of field experience with it yet. We’re in the process of validating it at early sites. We’ll know more in the near future. I wouldn’t put it in front of a client today as a production-ready solution, but I would call it worth watching closely.
We hope you found this article both intriguing and informative. At PMsquare, we specialize in cutting through the hype to deliver impactful, outcome-driven AI and analytics solutions. We help you build the data foundation, implement the right tools, and establish the governance needed to turn AI’s promise into your competitive advantage. If this is something you are looking for, contact us today.
Be sure to subscribe to our newsletter for more PMsquare updates and insights delivered straight to your inbox.
