Beyond the Basics: Advanced Capabilities for IBM i Agents

After explaining how to build agents for IBM i, IBM AI specialists Adam Shedivy and Devansh Kumar show how to transform those agents from useful tools into intelligent systems

Adam Shedivy Devansh Kumar December 2, 2025

Editor’s note: This article is part of the “AI With IBM i” blog. View other articles here.

There’s always room for improvement, and AI agents are no exception. In our previous article covering agents on IBM i, we built a performance monitoring agent that demonstrates a core pattern: SQL Services wrapped as tools, orchestrated by an LLM. But agents can become much more sophisticated. Let’s briefly explore four advanced capabilities that can transform your IBM i agents from useful tools into intelligent systems.

Memory: Agents That Learn

Memory gives agents the ability to store and recall information from previous interactions. Instead of treating every conversation as brand new, agents with memory can learn patterns and improve over time.

Imagine a security auditing agent that remembers which profiles were flagged last week, tracks which recommendations you’ve implemented and notices recurring patterns like “CPU spikes correlate with batch job X every Tuesday.” Over time, it builds institutional knowledge about your system’s behavior and security posture.

Storage: Maintaining Context

Storage enables agents to maintain conversation state across multiple interactions. Model APIs are inherently stateless, so each call is independent. Storage makes agents stateful, enabling natural multi-turn conversations.

Consider a change management agent helping with a complex deployment. You start the process in the morning (“Deploy the payroll update to TEST”), check progress at lunch (“How’s the deployment going?”), and review results in the afternoon (“Any errors?”). Without storage, each question exists in isolation. With storage, the agent maintains context throughout the entire workflow, remembering what “the deployment” refers to and tracking its state.

Knowledge: Domain-Specific Expertise

Knowledge is searchable, domain-specific information that agents can reference at runtime. Think of it as giving your agent a library of your organization’s documentation, policies and historical data stored in a vector database and retrieved when needed.

A production support agent with knowledge could search your internal documentation when troubleshooting, recall similar past incidents and their resolutions, reference your organization’s specific security policies and combine this institutional knowledge with real-time system data. The agent becomes an expert on your IBM i environment, not just IBM i in general.

Reasoning: Thinking Before Acting

Reasoning enables agents to “think” before responding and “analyze” the results of their actions. This dramatically improves reliability and quality, especially for critical operations.

A database maintenance agent with reasoning doesn’t just execute commands; it thinks through the impact on production first, considers timing and resource usage and analyzes whether operations had the intended effect. When you ask it to “optimize the ORDERS table,” it might recognize that it’s a high-traffic table during business hours and recommend scheduling maintenance during an appropriate window instead.

The Path Forward

These capabilities—memory, storage, knowledge and reasoning—can be combined to create agents that feel less like automation and more like experienced colleagues who understand your environment. An agent with all four capabilities could remember patterns from past incidents, maintain context across complex investigations, search your organization’s procedures and think carefully before taking action.

We’ll explore each of these concepts in depth in future posts, showing practical implementations and IBM i-specific patterns. For now, the key takeaway is this: The basic agent pattern we’ve demonstrated is just the starting point. As you get comfortable with tools and SQL Services, these advanced capabilities are available to take your agents to the next level.

And remember: No matter how sophisticated your agent becomes, IBM i’s SQL Services remain the foundation.

When (and When Not) to Use Agents

Before you start building agents for everything, understand the tradeoffs: Agents exchange speed and cost for flexibility. They’re slower than simple scripts, more expensive than direct SQL queries, and less predictable than traditional automation.

Use agents when you need flexibility and decision-making. If your task requires interpreting ambiguous requests, handling unpredictable scenarios or combining information in ways you can’t predefine—agents excel here. But if you have well-defined, repeatable processes? A SQL query, CL program or scheduled job is faster, cheaper and more reliable.

Start with the simplest solution that works. For many IBM i tasks, that’s a straightforward script using SQL Services directly. Reserve agents for scenarios where human-like judgment adds real value. You can always add agent capabilities later when the complexity is justified.

Key Takeaways: IBM i’s Agentic Advantage

We’ve covered a lot over the past three articles, from basic concepts to building a working agent to understanding when they’re worth the complexity. Let’s reflect on what makes IBM i particularly well suited for this approach.

Remember our performance monitoring agent? It retrieves system data, analyzes it and responds in plain English—all in about 50 lines of Python. The interesting part isn’t the agent code itself, but what we didn’t have to build: no middleware, no custom APIs, no integration layers. We connected directly to SQL Services and wrapped them as tools.

This simplicity isn’t accidental.

SQL as the Universal Interface

IBM i’s architecture makes agent development straightforward because virtually every system capability is already accessible through SQL. Security settings, performance metrics, job management and storage analysis are all queryable through built-in services. And there are over 370 of them.

You can explore the full catalog by querying QSYS2.SERVICES_INFO. These services span virtually every aspect of system operations:

Security: User profiles, authority management, audit logs
Performance: CPU metrics, memory pools, job statistics
Database: Object management, indexes, constraints, plan cache analysis
Work management: Job queues, subsystems, active jobs
Storage: ASP usage, disk allocation, object sizes
Journal: Change tracking, audit trails, database recovery
Ptf: Fix management, installation history
Backup and recovery: Save operations, restore tracking
Spool: Output queues, print management
IFS: Integrated File System navigation and management
System health: Problem detection, system values, resource monitoring
Message handling: System messages, job logs, alerts
Communication: Network connections, TCP/IP configuration
And many more …

Each service is a potential tool for your agent. The architectural decisions made decades ago now make agents remarkably practical to build.

The Repeatable Pattern

Building IBM i agents follows a consistent approach:

Identify the capability you want to expose (security auditing, performance monitoring, job management)
Find the SQL Service that provides it (query QSYS2.SERVICES_INFO to explore)
Wrap it as a tool using the pattern we demonstrated

No complex integrations. No custom connectors. Just SQL wrapped in Python functions.

From Retrieval to Action

Our example focused on retrieving data, but the same pattern works for taking actions:

Creating and managing user profiles
Starting and stopping jobs
Modifying security settings
Generating and distributing reports
Responding to system alerts

Each action is another SQL statement wrapped as a tool. The agent handles the decision-making; SQL handles the execution.

Practical Applications

Here’s what IBM i teams are building with agents today:

System administrators: Agents that monitor systems, diagnose issues, and suggest remediation
Security teams: Agents that continuously audit configurations and flag anomalies
Operations managers: Agents that generate reports, track metrics, and send alerts
Developers: Agents that assist with database management, deployment, and testing

The infrastructure is already there—mature SQL Services that have been refined over decades. The agent layer is just a new interface on top.

Starting Point

You don’t need sophisticated multi-agent systems on day one. Start with a single, focused use case:

A performance monitoring agent that answers ad-hoc questions
A security audit agent that flags unusual profile changes
A job management agent that helps troubleshoot failures

As you get comfortable with the pattern, expand capabilities by adding more SQL Service tools. Each new service you expose multiplies what your agent can do.

Join the Community

The open-source db2i-agents repository at github.com/ajshedivy/db2i-agents showcases different agent frameworks, design patterns, and use cases specifically for IBM i. It’s a practical resource for seeing what’s possible and accelerating your own development.

The Long-Term View

Most enterprise platforms are scrambling to make their systems accessible to AI agents—building new APIs, creating integration layers, documenting interfaces. IBM i already has this foundation through SQL Services that have been stable and comprehensive for years.

This isn’t about being cutting-edge for its own sake. It’s about practical advantages: when you decide an agent makes sense for a task, IBM i makes building it straightforward. The simplicity we demonstrated isn’t a demo trick—it’s representative of the actual development experience.

SQL Services were built for system management. They happen to be perfect for AI agents too.

What’s Next

This introduction barely scratches the surface. We’re actively building and experimenting with agentic AI for IBM i, exploring multi-agent systems, testing different frameworks, and discovering patterns that work well for system administration, security, and operations workflows.

One exciting project: We’re building an MCP (Model Context Protocol) server for IBM i. MCP is a standardized way to expose system capabilities to AI assistants. Think of it as a universal adapter that lets any MCP-compatible AI tool instantly access your IBM i system’s SQL Services. This means the same tooling we’ve demonstrated could work seamlessly across different AI platforms and applications. You can explore the project here.

In upcoming posts, we’ll dive deeper into:

Advanced agent patterns: Memory, knowledge bases, and reasoning in practice
Real-world use cases: Security auditing, performance optimization, and incident response agents
Multi-agent systems: How specialized agents can collaborate on complex tasks
The IBM i MCP server: How to use it and what it enables
Production considerations: Monitoring, error handling, and building reliable agent systems

We’re documenting what we learn and sharing working examples in the db2i-agents repository. If you’re experimenting with agents for IBM i, we’d love to hear what you’re building!