Share
Chris Chapman, June 15, 2026
Get the Best Solution
for Your Business Today!
Summary
TM1 and Planning Analytics environments are already well-positioned for AI agent integration thanks to a mature, comprehensive REST API that enables conversational access to nearly everything in the application – loading data, running TI processes, and querying cube values. AWS Bedrock AgentCore’s managed infrastructure reduces the build burden significantly by providing built-in memory and observability out of the box, solving two gaps that typically require multi-sprint custom work. The most common stumbling block is not technical: agents need a documented knowledge base of your specific TM1 environment before they can query reliably. For analytics teams ready to move, the practical path is to start with TM1, define a use case with clear success criteria, and complete the knowledge base work before anything goes live.
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
Why Is TM1’s REST API Well-Suited for AI Agent Integration?
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.
What Does AWS Bedrock AgentCore Add That Most Agent Frameworks Are Missing?
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.
Why Does Your Agent Need a TM1 Knowledge Base Before Going Live?
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.
Can AI Agents Be Used to Monitor a Cognos Environment?
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.
How Do You Get Started With AI Agent Integration in TM1?
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
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.
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.
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.
The honest answer is build time. A custom agent framework requires you to make decisions about memory architecture, choose and test a monitoring solution, and handle the plumbing that connects everything together. AgentCore ships with working answers to those problems. That doesn’t mean it’s the right choice for every situation, but for teams that want to get to the analytics use case without a multi-sprint infrastructure detour first, it removes real obstacles.
Agent memory is what allows an AI agent to retain context between sessions. Without it, every conversation starts at zero. The agent doesn’t know your TM1 environment, doesn’t remember the workflow you walked through yesterday, and has to be re-educated every time. For analytics use cases, that overhead essentially cancels out the time savings the agent was supposed to provide. Memory is what turns a demo into a tool people actually use.
It depends on the size and complexity of your TM1 environment, but budget real time for it before you go live with anything user-facing. You can partially automate the structural part by querying the TM1 server directly for cube and dimension information. The business context layer is inherently manual and teams that skip this step end up with agents that spend most of their time interrogating the environment rather than answering questions.
With a well-built MCP layer on top of TM1’s REST API, the range is close to everything you’d do inside the application. The main constraint isn’t the API, but whether the agent has been given enough context about your specific TM1 environment to navigate it reliably.
No. The point of the MCP approach is that it layers on top of what you already have. Your TM1 environment, your cube structures, your existing TI processes all stays in place. The agent becomes a new interface for interacting with it, not a replacement for it. Organizations that have spent years building sophisticated TM1 models have more to work with here, not less.
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.
