IBM · 2026
When the AI can’t hold the whole platform
Getting FlowPilot from demo to top priority
I joined FlowPilot, a month-old IBM prototype that builds integrations from plain English, as its first test user. I dug up the buried rules for building flows and turned them into a checked catalog of allowed actions.
- Role
- AI product management intern, webMethods Hybrid Integration
- Team
- The developer who built the prototype, senior product managers (PMs), and the user experience (UX) team
- Timeline
- May to August 2026
- What changed
- From a one-developer prototype to a roadmap item
This work is confidential, so there are no screens or internal details here. I’m happy to walk through it in an interview.
In short
- A specialist learns the legacy platform in about six months. FlowPilot aimed for a working integration in about a week.
- I converted 16 packages one at a time, rather than bundle more than 100 packages that no model could hold.
- The catalog became the spec for the first version, due to reach customers in late 2026.
Redrawn from memory, no customer data
- 01Customer needs an integrationSAP to Salesforce, say
- 02Specialist learns the legacy platformnew customers stall here
- 03Hand-builds it, package by package1,000+ pieces each
- 04Ships one flow at a time
Buried rules became a checked catalog
- 01Describe it in plain English“Sync new SAP orders daily”
- 02FlowPilot drafts itin VS Code
- 03Only from a checked catalog16 packages, each passing IBM’s validator
- 04Anything unchecked stays outnot in the first version
- 05Working integrations across 15 productsthe goal: inside systems customers already run
The target is a hypothesis until real specialists hit it.
My part
- Foundthe buried rules for building flows, and one file’s pattern that fit every package.Scenario-decision document
- Decidedto convert 16 packages one at a time and push back on one big bundle.Checked catalog of allowed actions
- Designedthe walkthrough that showed senior PMs how big the build was.
- Builta Python triage tool for the 20-person team that ranks the week’s top customer issues from the support Slack. It saved about an hour a day and ran on local models at zero budget, so customer conversations never left IBM.321 of 331 labeled tests passing
First test user
My own intern project wrapped up in three weeks, so I joined FlowPilot, an early experiment sketched by a team in London. At first my job was closer to research participant than product manager: try to build something real, and say what happened.
The problem
webMethods Hybrid Integration, the layer a business uses to trade with its partners, takes an integration specialist about six months to learn.
The harder problem was inside the team. The developer who built the prototype is exceptional, and assumed context that neither I nor the senior PMs had, so feedback from my tests pointed in different directions and nobody could say why.
After two weeks I couldn’t say what value I was adding, so I told my manager. He gave it one more week.
The turn
That week I found a buried, forgotten repository of rules for building flows. I read it the way a customer’s integration specialist would have to, so I stopped trying to understand the whole platform at once.
I mapped every decision in one file: if this, then do that. Then I tried the same pattern on every other service and package.
It fit every time.
That map became a scenario-decision document, which the developer confirmed customers could use. The questions I’d been asking became the walkthrough for the people setting priorities.
Decision log
to narrow the problem to one file, with one week left.
Rejectedkilling the project, as some developers suggested.
Whythe platform was too big to hold in my head. One file was not.
Resultthe map became the basis for the catalog.
to convert 16 legacy packages, one at a time, into a checked catalog.
Rejectedbundling more than 100 packages.
Whyeach held more than 1,000 pieces, and no model could keep that in context reliably. An integration that silently does the wrong thing is worse than one that refuses.
Resultthe catalog became the spec for the first version.
to walk the senior PMs through how complex the build was.
Rejectedpresenting the roadmap slide.
Whya slide would have kept the risk invisible.
ResultFlowPilot became a top priority, with five developers assigned.
to build first and show the developer something new every week.
Rejectedwaiting for stakeholders to agree on what FlowPilot was.
Whyworking artifacts moved the conversation in a way slides never did.
Resulteach week turned up a gap nobody had said out loud.
Alongside FlowPilot
- A request for three competitor battlecards grew into a 12-competitor, 30-slide sales toolkit once I interviewed the top sellers, who said competitors were winning on clearer AI messaging, not better AI features.
- An A/B test of new users’ first run, designed with the UX team: I built both tutorial formats and defined what better looks like. It runs after my internship.
Not in the first version
Image and voice input, multi-step orchestration across partners, and anything the validator couldn’t check.
What I would do differently
Push back earlier. I let conversations move past points we hadn’t aligned on, because that felt easier than admitting I was lost. The weeks started to click the moment I got upfront about what I didn’t know instead of protecting how I looked.
What I would do next
Instrument the first 10 integrations customers build and compare them with the six-month ramp, to see whether the one-week target holds for real specialists.
A postcard
From San Jose.
Downtown San Jose from the air, a 1943 Curt Teich postcard (Newberry Library; no known copyright). Click or tap the card to read the note on the back.
