The pieces are already there.

So far this series has looked at Bob as a developer's tool: reading RPG, modernizing it, testing it. That's how most IBM i shops will meet it. But a hands-on lab from TechXchange in October, published on GitHub, showed Bob doing something else entirely: running infrastructure.

In that lab, Bob works as an "Infrastructure Engineer," a custom persona that provisions and connects a live application across two clouds.¹ The participant states the outcome in a sentence. Bob writes the infrastructure code. None of it touches IBM i, but every ingredient it uses has an IBM i counterpart already in place.

What Bob does elsewhereA persona, some rules, and the right connections.

1. A custom mode. The "Infrastructure Engineer" persona is defined in the project's .bob/ folder, with its own rules for infrastructure-as-code standards and a skill file for the provisioning workflow.¹
2. MCP servers for the tools. Bob connects to Terraform, Ansible and Vault through MCP servers, and works through them rather than around them.¹
3. Least privilege from the start. Credentials come from least-privilege profiles injected through the environment, never stored in the project or typed into chat, and tokens are short-lived.¹

Custom modes are a standard Bob feature. The Premium Package for i adds its own IBM i Developer and Database modes, and any mode can be customized.⁶ The mechanisms the lab uses (custom modes, rules and connections to outside tools) aren't tied to one platform.

What IBM i already hasThe automation side already exists.

Every piece exists. What's missing is the connection: a Bob persona built for IBM i operations, working through the Ansible collection the platform already supports. The pieces are there. I haven't seen anyone put them together for IBM i operations yet, and what follows is a proposal, not something I've tested.

AI for the people who run the box is arriving from other directions too. Fresche's OpsIQ, launched in October, is a free, read-only assistant that investigates jobs, messages and authority errors in plain language and leaves the action to a person.⁹ The pattern here is a different one: Bob drafts the change as a playbook, a person approves it, and the platform runs and records it.

What it could look likeBob writes the change. The box runs it.

The key design choice for operations is this: Bob shouldn't run commands against a production system. It should write the playbook. A playbook is a change a person can read, review, version in git, run again, and hand to an auditor. It's also the artifact IBM i operations teams using Ansible already trust.

And the playbook is the part that lasts. It's plain text in your own repository, running on a collection IBM publishes openly. Change assistants next year and every playbook still runs. Bob writes the change, but the change belongs to you.

01

Bob drafts

An Ansible playbook, from a one-sentence request

02

A person approves

Reviewed like any change, then merged

03

Ansible runs it

On IBM i, under its own narrow profile

04

The box records it

In git and in QAUDJRN

There's a step zero. Ansible reaches IBM i over SSH, so the SSH server needs to be running (STRTCPSVR *SSHD). If you already use Bob with the Premium Package, it is: Code for IBM i connects over SSH too.⁸ The box also needs licensed programs 5733-SC1 (base and option 1) and 5770-DG1, plus Python with the itoolkit and pyodbc packages and the IBM i Access ODBC driver, installed through yum. Tasks that use SQL also need the database host server running. Ansible itself runs from a control node, which can be a Linux system or the IBM i itself.⁴⁷ If your shop doesn't run the open-source stack yet, that's a decision in its own right.

Start with reports, where nothing changes on the system. These are tasks every IBM i operations team does by hand today:

For a single partition, each of these reports takes a few SQL services queries (the fix currency check reaches out to IBM for current PTF levels, so it needs internet access); Ansible earns its place across many partitions and for repeatable changes. Once the reports are trusted, the same pattern extends to changes: applying fixes in a maintenance window, setting a profile's expiration, restarting a service. Each one is a reviewed playbook rather than a command typed at a prompt.

Why governance matters more hereOperations touches the running system.

A code change goes through compile, test and promotion before it reaches production. An operations change often doesn't. That's why the model in Chapters 03 and 04 matters even more here:

1. Separate identities for separate jobs. Bob's profile drafts; the automation's profile runs. Neither should be the other, and neither should be a person's everyday sign-on.
2. Grant only what each job needs. Some operations tasks genuinely need special authorities, such as job control or save authority. Give the automation's profile only what its playbooks require, and use authority collection to confirm it. Keep its password or key in a vault, never in plain text on the control node.
3. Keep Bob's approvals on. Leave command and edit approvals on for the operations persona and limit its tool groups to read-only. Then connect it with a read-only profile, so the box enforces the limit, not just the mode, until the reports have earned trust.
4. Treat SSH as a door. Turning it on adds a way into the system. Put it on your inventory, restrict who can use it, and log it like any other path in.

Bob writes the change. A person approves it. The box runs it and records it.

What to do MondayThree moves to try the pattern.

I'll report back on trying this in Chapter 06.