Robots & Pencils Enriches Studio for Generative and Agentic AI with Addition of Brendan Flynn as SVP, Strategy
Robots & Pencils
Flynn brings two decades of large-scale product engineering and delivery leadership, with a track record of building the operating model that lets enterprise AI scale.
Robots & Pencils, an applied AI engineering partner designed for enterprise velocity and measurable business impact, today announced the appointment of Brendan Flynn as Senior Vice President, Strategy within Robots & Pencils’ Studio for Generative and Agentic AI in Bellevue, Wa. Flynn will work with clients to ensure the strategies behind their AI investments scale and deliver the defined business outcomes.
Robots & Pencils has built its business around a solution-delivery flywheel, accelerating the velocity of delivery and client impact with live solutions launching weeks, not quarters. Flynn’s mandate is clear. Deliver the business outcomes for which clients are investing and put the foundation in place for agentic transformation to scale across the enterprise.
A Career Forged in Scale and Speed
Flynn hails from Capgemini, where he led large-scale product engineering and AI transformations for global brands in QSR, hospitality, and enterprise software.
His reputation is built on a rare pairing: the organizational change management expertise to shift how a company works, and the product engineering discipline to make the shift hold.
“Two decades working inside large Global Systems Integrators showed me exactly where the legacy delivery model strains under the demands of enterprise AI,” Flynn said. “That gap is why I’m here. Robots & Pencils was built to close it — and that’s what delivers the outcomes enterprises are chasing.”
Velocity Compounds by Design
The Robots & Pencils operating rhythm compounds by design. Production solutions reach testable market fit in weeks, not quarters, and from there rigorous evaluations turn real usage into the signal that drives learning, optimization, and scale. Flynn’s role is to align that rhythm to how each client runs, so the pace holds once the engagement scales.
“Executives are past the pilot stage. They want to know what changes in the P&L and when,” Flynn said. “Starting from proven patterns moves the conversation from ‘can this work’ to ‘what does this deliver, on what timeline, and what has to change in the organization to keep it running.’”
A Leader Built for This Moment
“Agentic AI enables companies willing to transform how the work itself gets done, not the ones that bolt it on,” said Len Pagon Jr., CEO of Robots & Pencils. “That rethinking takes a strategy set before the first line of code. Brendan has solved that problem before, at real scale. He’s been the client, and he’s been the partner. That combination is rare. Clients feel it in the first conversation.”
Robots & Pencils is unabashedly all in on AWS, and Flynn’s strategy work is aimed squarely at helping enterprise leaders get more from their AI investments and more from their investments in AWS.
“Live in weeks vs. quarters change the conversation,” Flynn said. “When a client sees something real in production that fast, the question stops being whether AI works and starts being how fast we can do it again. That is the moment I want to create, over and over.”
Pt. 1: Repo-Native Delivery – Why We Ditched Jira for AI Work
Nilesh Patwardhan
How we moved from Jira + AI connectors to a single repo where humans and agents work from the same source of truth.
Part 1 of 2: The why. Part 2 walks through the operating model itself.
Almost every product tool I open lately is reaching for the same idea: put an AI copilot on top of the backlog. Jira has Rovo. ServiceNow ships agile story generation that claims to cut epic breakdown by around 80%. Linear, Azure DevOps, and the rest are adding a button that turns a fuzzy feature into a tidy stack of tickets.
That is genuinely useful. I do not want to wave it away.
The version I run into most these days is subtler. Plenty of teams now connect Jira to their AI assistant as an MCP connector (in Claude’s Cowork, for instance) so the assistant can read and update tickets for them. For a solo PM, that can feel like a small miracle. The assistant can summarize the board, draft updates, and move work along without the usual tab-hopping.
But the shape of the system has not really changed.
The tracker is still a second system the AI has to reach into over an API, one round trip at a time. Someone still has to keep that system in sync with the work. The integration layer did not disappear. It just got automated.
Which leaves a more interesting question sitting in the open:
If AI can generate the work, and read the work, do we still need the tracker to be the home of the work?
At Robots & Pencils we build AI products for enterprises, which means we have felt the gap between how these systems get built and how we were managing the building. On a recent enterprise pilot, I started an experiment: run delivery without Jira as the source of truth.
Generate the epics and stories from a skills pipeline. Let the whole team (PM, designer, engineer) work out of a Git repo where stories, sprints, and decisions are versioned markdown files.
The goal was not a tidier way for me, the PM, to manage a project from my own AI session. That would have been a nicer cockpit, not a better operating model.
The goal was to put the whole team on one source: the engineer in their editor, the designer in theirs, no connector in the middle, and nobody waiting on me to sync a board.
It worked well enough that it is quietly becoming how we deliver AI-native work.
This piece is the why. The next one is the how.
The tell: who’s doing the integrating
Jira makes the human the integration layer.
The work is there, but it is scattered into pieces: the ticket, the related tickets, the research doc, the decision from three weeks ago, the acceptance criteria that changed in grooming, the Slack thread nobody quite remembers.
Before anyone can move, someone has to stitch the picture together.
That was a reasonable deal when the only thing that could read a ticket was a human.
It’s a worse deal now.
The assistant doing more of the building can read the surrounding context, if the context is somewhere it can actually reach. When a story is a markdown file in the repo, the assistant can take in the story, the technical spec, the grooming notes, and the code itself in one pass, because they’re all just files in the same working surface.
Nobody has to describe the map. The assistant can follow the links.
Wiring the tracker into an AI assistant over MCP is still progress. It hands some of that assembly work to the assistant. But it also preserves the old shape: second system, API round trips, and a project record that has to be kept aligned with the place where the work is actually happening.
Repo-native delivery asks for a cleaner cut.
Move the artifacts to where the work and the AI already live, and the integration layer stops being a person.
Tracker-plus-MCP keeps a second system and API round-trips; repo-native lets the editor read story, spec, grooming, and code in one pass.
What about Linear?
Linear is excellent. It is what a better tracker looks like: clean, fast, developer-friendly, with strong GitHub integration and improving AI. Plenty of teams, including parts of ours in the past, moved happily from Jira to Linear.
But even Linear is still a tracker. The work artifacts live in Linear’s database. The AI reaches in through integrations. Engineers still cross from the issue tracker to their editor and back. The fundamental shape, a separate coordination system sitting next to the execution environment, stays intact.
Repo-native delivery goes one step further. It asks whether we still need that separate system at all, once context is cheap and an assistant can read across stories, specs, decisions, and code in one pass. We are not trying to replace Jira or Linear with a nicer interface. We are moving the source of truth into the environment where the work, and the agents, already live.
What changes when the repo is the truth
The benefit I expected was speed.
The benefit that actually mattered was quieter seams between people.
The engineer felt it first. Their coding agent could open a story with the real acceptance criteria in context, not a paraphrase pasted into a chat window. That meant the agent built toward the definition of done instead of drifting toward a plausible interpretation of it.
Even better, the criteria became something the agent could check its own work against. The story was not just an instruction. It was the contract.
And the engineer never left the editor to find any of it. The story, the plan, and the reasoning sat beside the code, not behind another login.
Handoffs changed too.
A designer could drop an artifact and a one-line note into the story folder, and the next person’s editor would read it when they opened the story. No tagging. No “did you see my message?” No quiet dependency on someone remembering to move context from one place to another.
The same source also starts feeding many views. One status.md file can become the morning brief, the sprint risk log, the retro, and the stakeholder report.
You author once and query many ways.
That is where the repo has an advantage over the tracker. A tracker’s data mostly feeds the tracker’s own views. Repo data feeds anything a team can write a prompt for.
The query I lean on most isn’t a fancy one. Each morning, instead of asking the team what they did yesterday, I ask the repo.
Traditional: each role’s work scatters into meetings, messages, tickets, and status updates that someone reconstructs later. Repo-native: every role’s work accumulates in one shared operational record that assistants read and enrich.
Jira is a coordination layer. The repo is where execution happens.
The same assistant helping implement a story can also summarize sprint risk, trace dependencies, draft stakeholder updates, and explain why a decision was made.
When the same system can participate in both coordination and execution, the boundary between the two starts to look less inevitable.
That shift shows up in small ways at first.
The prompts we run do not stay prompts. A query used a few times becomes a skill. The skills, plus the repo structure and conventions, become a scaffold. And that scaffold is portable.
The next engagement does not begin with an empty Jira project. It begins from a template that already knows how stories, sprints, decisions, prompts, and ceremonies fit together. The operational cost of standing up a new project drops because the operating layer already exists.
That is what turns a workflow into a capability.
It also reframes the PM’s job.
When a skill can draft the stories, the PM’s edge moves upstream: framing the right epics, encoding judgment into the pipeline, and curating the context the whole team’s tools draw from.
The craft shifts from producing the backlog to designing the system that produces it.
The judgment was always there. Now it has somewhere explicit to live.
Maybe the bigger question is not how we teach our trackers to work with AI.
Maybe it is whether the work still needs a separate coordination system at all.
Was the tracker ever the right home for the work in the first place?
Ours moved into the repo, and it has not asked to move back.
Stay tuned forPart 2, where Nilesh walks through the operating model: the two-repo pattern, the story directory, the sprint-as-narrative, and how every ceremony ends in a commit, so you can copy it, not just nod at it.
