Maximo AI Service in 2026: From Demo to Production in 6 Weeks With the Agentic Workflow Pattern

The Maximo AI Service (formerly Maximo Assistant) has been the most over-promised and under-used feature in the MAS stack for three years. In 2026, it is finally production-ready, and the customers running it in production are seeing 20-50% reductions in mean time to resolution for the top 10 operational use cases. The difference between "demo" and "production" is the agentic workflow pattern — a planner, a set of tools, and a guardrail.

This article is the 6-week implementation playbook for the agentic workflow pattern, based on the work at a US utility (work order triage), a global facilities management company (PM optimization), and a North American rail operator (predictive dispatch). The playbook is repeatable, the tools are documented, and the guardrails are non-negotiable.

What changed in 2026

Three things changed in the Maximo AI Service in MAS 9.1.x (released between January and May 2026):

1. The Agentic Workflow Engine is GA. It is a planner-executor architecture that lets the LLM break a task into steps, call tools, observe results, and adapt. The previous "chat with my data" model was a single-turn Q&A. The new model is a multi-turn, multi-tool workflow.
2. The Tool Catalog is open. Customers can register custom tools (REST endpoints, MIF object structures, automation scripts) and the agent can call them. The catalog ships with 50+ pre-built tools (work order query, asset query, inventory query, failure history, etc.).
3. The Guardrail Service is integrated. It is a set of pre-prompt and post-prompt checks that enforce the "no PII, no SQL injection, no destructive action, no hallucination" rules. The guardrail is mandatory for any production deployment.

The combination is the difference between a chatbot and an operational tool. A chatbot answers questions. An operational tool takes actions — it creates work orders, schedules PMs, dispatches crews, and updates assets. The agentic workflow pattern is how you build the operational tool.

The agentic workflow pattern

The pattern has three components:

1. The planner — an LLM (Granite 4.0 Instruct on watsonx.ai, by default) that breaks a natural-language request into a plan of action.
2. The tool catalog — a registry of REST endpoints, MIF objects, and automation scripts that the planner can call.
3. The guardrail — a set of pre-prompt and post-prompt checks that enforce the safety rules.

# The agentic workflow pattern — abbreviated
from ibm_watsonx_ai import APIClient
from ibm_watsonx_ai.foundation_models import Model

# 1. The planner
planner_prompt = """
You are an operational agent for a Maximo environment.
Break the user's request into a sequence of tool calls.
Use the available tools to gather data and take action.
Always validate the output before returning.
If a tool returns an error, retry up to 2 times.
If the error persists, escalate to a human.
"""

# 2. The tool catalog
tools = [
    Tool(
        name="get_workorder",
        description="Retrieve a work order by number",
        endpoint="/mif/oslc/os/mxapiwo",
        method="GET",
        parameters={"wonum": "int"}
    ),
    Tool(
        name="create_workorder",
        description="Create a new work order",
        endpoint="/mif/oslc/os/mxapiwo",
        method="POST",
        parameters={"description": "str", "priority": "int"}
    ),
    Tool(
        name="get_asset_history",
        description="Retrieve asset history",
        endpoint="/mif/oslc/os/mxapiasset",
        method="GET",
        parameters={"assetnum": "str"}
    ),
    # ... 50+ pre-built tools ...
]

# 3. The guardrail
guardrail = Guardrail(
    pii_filter=True,
    sql_injection_check=True,
    destructive_action_check=True,
    hallucination_check=True,
    escalation_user="maxadmin"
)

The pattern is the same for any use case. The planner prompt changes, the tool catalog changes, the guardrail is constant.

The 6-week implementation playbook

Week 1: Use case selection

The most common AI deployment mistake is scope creep on use cases. The team says "let's automate everything," the project is in scope for everything, and the deployment never delivers. The fix: pick 1-3 use cases for the pilot, total.

A good use case for the agentic workflow pattern has these properties:

• High volume — the agent does the work hundreds of times a day
• Clear data sources — the tools are MIF objects, not custom integrations
• Clear action — the output is a work order, a PM, a dispatch, a record update
• Clear success metric — time saved, errors reduced, throughput increased

Examples that work:

• Work order triage — read the incoming work order, classify the priority, suggest the craft, suggest the asset, suggest the parts. Reduces triage time from 8 minutes to 30 seconds.
• PM optimization — read the PM history, the work order history, the failure history, suggest a frequency adjustment, a job plan update, or a route change. Reduces PM backlog by 20-40%.
• Predictive dispatch — read the asset health, the crew location, the work order queue, suggest the next dispatch. Reduces mean time to dispatch by 30%.

Week 2: Tool catalog design

For each use case, design the tool catalog. The catalog is the API surface the agent can call. The default set includes:

• get_workorder, get_workorder_history, create_workorder, update_workorder
• get_asset, get_asset_history, update_asset
• get_inventory, update_inventory
• get_person, get_person_calendar
• send_email, send_notification
• create_worklog, create_failure_report
• get_health_score, get_predict_score

The tool catalog is the most important design decision in the implementation. If the catalog is too small, the agent cannot do its job. If the catalog is too large, the agent gets confused and calls the wrong tool. The sweet spot is 8-15 tools per use case.

Week 3: Guardrail configuration

The guardrail is non-negotiable. It is the layer that prevents:

• PII leakage — the agent sees a person record with a SSN, the guardrail redacts the SSN before the LLM sees it.
• SQL injection — the agent generates a SQL query, the guardrail validates it against an allow-list of tables and columns.
• Destructive actions — the agent tries to call a DELETE endpoint, the guardrail blocks it.
• Hallucinations — the agent returns a work order that does not exist, the guardrail validates against the MIF before returning.

The guardrail is configured in the Maximo AI Service Admin application. The configuration is a YAML file that defines:

• The PII fields to redact
• The SQL allow-list
• The destructive action blocklist
• The MIF validation rules

guardrail:
  pii_fields:
    - PERSON.SSN
    - PERSON.DRIVERLICENSE
  sql_allowlist:
    tables: [ASSET, WORKORDER, INVENTORY, PERSON, LOCATION]
    operations: [SELECT]
  destructive_actions:
    blocklist: [DELETE, DROP, TRUNCATE]
  mif_validation:
    object_structures: [MXAPIWO, MXAPIASSET, MXAPIINV]
    require_existence_check: true

Week 4: Planner prompt engineering

The planner prompt is the LLM prompt that breaks the user's request into a sequence of tool calls. It is the second most important design decision in the implementation. The prompt is a few hundred lines, not a few. It includes:

• The system prompt — the agent's role, the agent's constraints, the agent's escalation policy
• The tool descriptions — each tool's purpose, its parameters, its expected output
• The examples — 10-20 example plans for the use case
• The error handling — what to do when a tool fails, what to do when the data is missing, what to do when the request is ambiguous

planner_prompt = """
You are an operational agent for a Maximo work order triage system.

# Your role
You receive an incoming work order description and you must:
  1. Classify the priority (1-5)
  2. Suggest the craft (electrical, mechanical, instrumentation, etc.)
  3. Identify the asset
  4. Suggest the parts
  5. Suggest the duration

# Your constraints
- You must use the available tools to gather data
- You must validate the asset exists before suggesting it
- You must not invent parts that are not in the inventory
- You must escalate to a human if the description is too ambiguous

# Your tools
- get_workorder(wonum) -> WorkOrder
- get_asset(assetnum) -> Asset
- get_asset_history(assetnum, days=90) -> [WorkOrder]
- get_inventory(itemnum) -> Inventory
- get_failure_codes(assetnum) -> [FailureCode]

# Examples
Example 1:
  Description: "Pump P-101 is making a loud noise"
  Plan:
    1. get_asset_history(assetnum="P-101", days=90)
    2. get_failure_codes(assetnum="P-101")
    3. Return priority=2, craft=mechanical, parts=[bearing-001, grease-002], duration=4
"""

The prompt is iteratively refined over week 4. The first draft gets 60% of the use cases right. The 10th draft gets 90%.

Week 5: Integration testing

The integration testing is where the agent meets the real Maximo environment. The flow:

1. Spin up a non-prod MAS instance with a copy of the production data (sanitized).
2. Run 100 test cases through the agent, with the expected output recorded.
3. Measure the pass rate. A 90% pass rate is the minimum for production.
4. Tune the prompt and the guardrail until the pass rate is 95%+.
5. Document the failure modes — what does the agent do wrong, and why.

The integration testing is the third most important design decision in the implementation. A prompt that works on 100 hand-crafted examples often fails on 100 real-world examples. The fix is iteration.

Week 6: Production cutover and monitoring

The production cutover is the deploy. The flow:

1. Deploy the agent to the prod MAS instance, in monitor-only mode (the agent returns suggestions, but does not take actions).
2. Run for 1 week in monitor-only mode to validate the suggestions are correct.
3. Switch to action mode (the agent takes actions, but with a 5-minute human approval window).
4. Run for 2 weeks in action mode with approval to build user trust.
5. Switch to full autonomous mode for the high-confidence use cases, keep approval mode for the low-confidence ones.

The monitoring is the fourth most important design decision in the implementation. A Grafana dashboard with these panels is the minimum:

• Agent response time (p50, p95, p99)
• Agent pass rate (correct suggestion / total suggestions)
• Agent tool call volume (by tool, by user)
• Guardrail blocks (by rule, by user)
• Escalation rate (by use case, by user)

The 80/20 of agentic workflows

The agentic workflow pattern is the 80/20 of AI in Maximo. The 80% of the value comes from the 20% of use cases that are high-volume, clear-data, clear-action, clear-metric. The other 80% of use cases (the bespoke, the custom, the edge case) are not worth the agentic workflow investment in 2026.

The customers who have done this well in 2026 are the ones who picked the 1-3 use cases, deployed the agent in 6 weeks, measured the ROI, and expanded from there. The customers who are still "evaluating" are running the same 6-week pilot in 18 months, having lost a year.

The bottom line

The Maximo AI Service is production-ready in 2026. The agentic workflow pattern is the difference between a chatbot and an operational tool. The 6-week implementation playbook is the recipe for the first deployment. The customers who are running it in production are seeing real ROI. The customers who are not are running the same demo they have been running for three years.