“Responsible for developing scalable cloud applications using AWS.” 

Esa frase no me dice nada, no porque esté mal escrita, sino porque podría pegarla en cien hojas de vida distintas y encajaría igual de bien en todas. Cada semana leo líneas así de candidatos que claramente construyeron cosas reales, y cada semana esas cosas reales se quedan invisibles detrás de una descripción de cargo. 

Esto es exactamente lo que pasa por mi cabeza la primera vez que abro una hoja de vida. No la versión pulida que te contaría en una entrevista. La real. 

Presiona play aquí abajo y compruébalo por ti mismo. 

Preguntas frecuentes 

¿Por qué no basta con decir que construí “aplicaciones escalables”? 

Un candidato escribe “responsible for developing scalable cloud applications using AWS.” No dudo que hizo el trabajo. Dudo que yo pueda saber cuál fue ese trabajo. 

Ahora mira la reescritura. “Designed and deployed an event-driven AWS platform using AWS Lambda, Amazon SQS, and Amazon DynamoDB, processing more than 3 million events daily.” Mismo candidato, mismo proyecto, hoja de vida completamente distinta. Ya sé el patrón de arquitectura. Ya sé la escala. Ya sé qué servicios de AWS usó de verdad y cómo encajan entre sí. Una frase me obligaba a adivinar. La otra construyó el caso. 

¿Basta con enumerar las herramientas que domino, como Python, AWS o Kubernetes? 

Python, Java, AWS, Azure, Kubernetes, Terraform, Kafka, Amazon Bedrock, LangChain. Suena impresionante. También me dice casi nada, porque una lista de herramientas sin un problema al lado es solo una hoja de vida disfrazándose de currículum sólido. Cualquiera puede nombrar la tecnología. Muy pocos pueden explicar la decisión detrás de ella. 

¿Cómo debo describir mi experiencia con inteligencia artificial? 

Ese trabajo hoy aparece en todas las hojas de vida. “Built an AI-powered chatbot using RAG and LLMs” me llama la atención por unos dos segundos, hasta que necesito la siguiente frase. ¿Qué problema resolvía, qué modelos usó, y cómo sabía que estaba funcionando? Guardrails y observabilidad dejan de ser palabras de moda cuando puedes señalar el momento exacto en que importaron. Ahí está la diferencia entre un candidato que desplegó algo real y uno que vio un tutorial. 

¿Cómo debo presentar mi experiencia liderando con clientes? 

“Led technical discovery sessions with US enterprise clients and translated business requirements into AWS architecture decisions” es una línea fuerte, y lo digo en serio. El trabajo con clientes combinado con criterio de arquitectura es justo lo que necesitan los roles senior. Pero pesa más al lado de una construcción concreta, no en lugar de ella. Muéstrame que puedes sentarte frente a un cliente, y luego muéstrame qué entregaste después de esa reunión. 

¿Cuál es la diferencia entre describir una responsabilidad y demostrar un impacto? 

Esta es la que enmarcaría. “Improved application performance” contra “reduced API latency by 40%.” “Built a data pipeline” contra “built a pipeline processing 10 million records daily.” Mismo trabajo, treinta segundos de diferencia, y ya sé cuál candidato recibe la llamada. 

Una responsabilidad me dice qué te asignaron. Un impacto me dice qué cambió porque tú apareciste. No busco adjetivos. Busco el número que solo existe porque hiciste el trabajo. 

¿Debo incluir habilidades blandas como “apasionado” o “buen trabajo en equipo”? 

“Passionate about technology, results-driven, professional, excellent team player.” Probablemente todo cierto, y también cierto en cada hoja de vida de la pila. Tu carácter nunca fue la pregunta. La diferenciación sí, y esta línea no tiene ninguna. 

¿Qué debo revisar antes de enviar mi hoja de vida? 

¿Qué construiste realmente? ¿Cuál era el alcance, y para quién era? ¿Qué número cambió por tu trabajo, y puedes defenderlo en una entrevista? Si un reclutador sin formación técnica leyera esta línea, ¿se iría con una imagen clara de lo que hiciste, o con una lista de cosas que sabes? 

En resumen, ¿qué es lo que realmente buscan al leer mi hoja de vida? 

Treinta segundos es todo lo que tiene una hoja de vida antes de que yo decida si sigo leyendo. Gástalos en lo que construiste, en lo que logró a escala, y en lo que cambió porque tú fuiste quien lo hizo. Esa es la hoja de vida que se lee dos veces. 

Ya sabes qué contar. Ven a contárnoslo. 

Si eres un ingeniero construyendo cosas que valen la pena contar, tenemos un lugar para esa historia. Explora las vacantes abiertas en Robots & Pencils y muéstranos qué construiste. 

English Version 

You Have Thirty Seconds. Make Them Count. 

“Responsible for developing scalable cloud applications using AWS.” 

That sentence tells me nothing, not because it’s wrong, but because I could paste it into a hundred other resumes and it would still fit. Every week I read lines like this from candidates who have clearly built real things, and every week those real things stay invisible behind a job description. 

Here’s exactly what runs through my head the first time I open one. Not the polished version I’d give in an interview debrief. The real one. 

Press play below and see it for yourself. 

Frequently asked questions 

Why isn’t it enough to say I built “scalable applications”? 

A candidate writes “responsible for developing scalable cloud applications using AWS.” I don’t doubt they did the work. I doubt I can tell what the work was. 

Now look at the rewrite. “Designed and deployed an event-driven AWS platform using AWS Lambda, Amazon SQS, and Amazon DynamoDB, processing more than 3 million events daily.” Same candidate, same project, completely different resume. I know the architecture pattern. I know the scale. I know which AWS services they actually touched and how those services fit together. One sentence made me guess. The other made the case. 

Is it enough to list the tools I know, like Python, AWS, or Kubernetes? 

Python, Java, AWS, Azure, Kubernetes, Terraform, Kafka, Amazon Bedrock, LangChain. Impressive lineup. It also tells me almost nothing, because a list of tools without a problem attached is just a resume playing dress-up. Anyone can name the technology. Fewer people can explain the decision behind it. 

How should I describe my AI experience? 

That work is everywhere on resumes right now. “Built an AI-powered chatbot using RAG and LLMs” gets my attention for about two seconds before I need the next sentence. What problem did it solve, which models did you use, and how did you know it was working? Guardrails and observability aren’t buzzwords when you can point to the moment they mattered. They’re the difference between a candidate who deployed something real and one who watched a tutorial. 

How should I present my experience leading client work? 

“Led technical discovery sessions with US enterprise clients and translated business requirements into AWS architecture decisions” is a strong line, and I mean that. Client-facing work paired with architectural judgment is exactly what senior roles need. But it lands harder next to a concrete build, not instead of one. Show me you can sit across the table from a client, and then show me what you delivered after that meeting. 

What’s the difference between describing a responsibility and demonstrating impact? 

This is the one I’d put in a frame. “Improved application performance” versus “reduced API latency by 40%.” “Built a data pipeline” versus “built a pipeline processing 10 million records daily.” Same work, thirty seconds apart, and I already know which candidate gets the callback. 

A responsibility tells me what you were assigned. An impact tells me what changed because you showed up. I’m not looking for adjectives. I’m looking for the number that only exists because you did the work. 

Should I include soft skills like “passionate” or “team player”? 

“Passionate about technology, results-driven, professional, excellent team player.” All true, probably, and all true of everyone else’s resume in the stack too. Your character was never the question. Differentiation is, and this line doesn’t have any. 

What should I check before I send my resume? 

What did you actually build? What was the scope, and who was it for? What number changed because of your work, and can you defend it in an interview? If a recruiter with no technical background read this line, would they walk away with a picture of what you did, or a list of things you know? 

So what are you really looking for when you read my resume? 

Thirty seconds is all a resume gets before I decide whether to keep reading. Spend them on what you built, what it did at scale, and what changed because you’re the one who did it. That’s the resume that gets read twice. 

You know what to tell us. Come tell us. 

If you’re an engineer building things worth writing about, we have a place for that story. Explore open roles at Robots & Pencils and show us what you built. 

The post Tienes treinta segundos. Que cuenten.  appeared first on Robots & Pencils.

In Part 1, I argued that a tracker quietly makes humans the integration layer, and that moving delivery artifacts into the repo hands much of that assembly work to the tooling. 

This is the operating model that fell out of that idea. 

The goal is simple: 

Every artifact should be readable by both a human and an assistant without translation. 

Stories, decisions, sprint history, status updates, technical plans, reports: all of it lives in a form that the team can read directly and that an assistant can traverse without APIs, connectors, or synchronization. 

None of this is exotic. It’s markdown files, Git, and an agent-aware editor like Cursor or Claude Code. 

The discipline is what makes it work. 

Two repos, two rhythms 

The first decision is to stop forcing artifacts and code to share a history. 

They have different cadences, different gates, and different owners. 

So they get different repos. 

The delivery repo holds artifacts only: stories, sprints, decisions, context, prompts, and reports. 

The code repos stay exactly as they should be: feature branches, pull requests, CI, and release workflows. 

Each code repo’s CLAUDE.md points back to the delivery repo so that any assistant reading the code also has access to the project’s intent and decisions. 

That separation solves a surprisingly common problem. 

Trackers go stale because updating them competes with shipping code. When artifacts live in their own frictionless repo, there is nothing competing for attention. A decision or status update takes seconds to commit and lands immediately. 

No connector, no second system 

There is no tracker and no connector. 

The files are the context. The same editor the engineer uses to build is where the assistant reads stories, specifications, decisions, and status. 

That is also why this is a team model rather than a PM productivity hack. 

Managing a project through a Jira connector is something one person does from their own AI session. Here, everyone works from the same source. Engineers build from it. Designers contribute to it. Reports generate from it. 

Nobody waits for a board to catch up. 

The story is a directory, not a ticket 

Our unit of work is a folder, not a line item. 

A story directory holds a few files, each with one job: 

Together they form the work surface. 

When an engineer opens a story, the assistant sees the same picture they do: the requirements, the implementation plan, prior decisions, open questions, and evidence. 

Dependencies are recorded as simple wikilinks such as [[E2-1]], giving assistants a graph they can traverse rather than a collection of disconnected tickets. 

For engineers: a control plane, not PM docs in Git 

It would be easy to read all of this as project managers moving their paperwork into Git. That is not what it is. 

For an engineer, the repo turns delivery artifacts into part of the work surface, instead of a parallel system to keep in sync. 

Start with the thing engineers feel every day: context switching. Recovering intent from a tracker means leaving the editor, finding the ticket, reading a description written weeks ago, and scanning the comments. Here, story.md, technical-spec.md, and grooming.md sit beside the code. You read the contract, the plan, and the reasoning without leaving Cursor, and so does your agent. 

It also front-loads the ambiguity. The spec-drafting prompt asks the agent to flag acceptance criteria that are vague or untestable before any code gets written, so you are not halfway through a build when you realize the AC could mean two things. 

Evidence lives with the work. artifacts/ is the natural home for eval outputs, screenshots, scorecards, generated datasets, and review forms. When someone revisits the story to debug or review, the proof is right there, not scattered across Drive and Slack. 

Dependencies are plain text. A wikilink like [[E2-3]] is easier to traverse than a tracker’s dependency UI, for you and for the agent, and you can grep the whole tree. 

The code ties back to the contract. Code repos point at the delivery stories, and tests validate the acceptance criteria in story.md, so a reviewer checks against a real definition of done rather than “matches the ticket.” 

The quiet win under all of it: no stale duplicate truth. A tracker usually becomes a second copy of what the engineer learned while building, and it drifts the moment the build teaches you something. Here, when the spec changes, the same repo captures the change, the reason, and the evidence, in one place. 

A lightweight engineering control plane, where context, decisions, specs, evidence, and status live where developers and agents can use them directly. 

The coding agent inherits the contract 

When a coding agent opens a story, it inherits the contract. 

The story, acceptance criteria, technical spec, grooming notes, and code all sit in the same context window. 

Before implementation starts, the engineer has the agent draft technical-spec.md from the story and checks that the plan actually matches the intent. 

Misunderstandings surface in prose instead of three commits later. 

Then the acceptance criteria become something the agent can actively steer toward. 

The definition of done is no longer a memory of a meeting. It is a file sitting beside the code. 

That changes behavior. Agents drift less. They gold-plate less. They spend less time solving adjacent problems and more time solving the one the story actually describes. 

In a tracker-centric workflow, those criteria often live somewhere the coding agent never looks. 

The sprint is a narrative, not a board 

If the story is the unit of work, the sprint is the unit of time. 

One sprint. One file. 

The sprint document contains the goal, committed stories, a running log of mid-sprint events, delivered work, and the retro. 

The key rule is append-mostly. 

Committed work stays committed. When reality changes, and it always does, you add an event explaining what changed and why. 

The sprint becomes a readable history instead of a constantly rewritten snapshot. 

That turns out to be useful for both retrospectives and stakeholder conversations. 

Decisions live where their scope lives 

One small rule removes a surprising amount of friction. 

Story-level decisions live with the story. 

Sprint-level decisions live in the sprint file. 

Project-level decisions live in /decisions/. 

Six months later, when someone asks why a choice was made, there is a dated file with the answer. 

Every ceremony ends in a commit 

The decision lives in the file before the meeting ends. 

If “I’ll update it later” creeps back in, the model degrades into Jira-by-other-means within a sprint. 

Planning, standup, review, and retro all follow the same pattern: 

1. Read the repo. 

2. Make decisions. 

3. Commit the outcome. 

The ceremony is the conversation. 

The commit is the memory. 

The same data feeds all of these. 

A single status.md file becomes the morning brief, the risk log, the retro, and the stakeholder report. 

You author once and query many ways. 

Status itself remains human-owned. The assistant drafts it from commits and chat context, but a person reviews and commits the result. Otherwise the no-code days (debugging dead ends, credential issues, design discussions) disappear from the record. 

Where it becomes an asset 

Prompts do not stay prompts. 

A query used a few times becomes a skill. 

The skills, plus the directory structure and conventions, become a scaffold. 

The scaffold becomes reusable. 

The next engagement starts from a template that already knows how stories, sprints, decisions, and ceremonies fit together. 

The cost of standing up a new project keeps dropping because the operating layer already exists. 

One principle keeps that from tipping into over-automation: 

Automate aggregation and synthesis. Do not automate judgment. 

Draft the brief. Draft the retro. Draft the report. 

But decisions, scope, priorities, and commitments stay human. 

The moment you automate judgment, the model quietly rots. 

What it costs, honestly 

It isn’t free. 

The committing discipline is load-bearing, and no tool nags you into doing it. 

It assumes the team works in an agent-aware editor. Open these files in a plain editor and much of the leverage disappears. 

Design tools do not go away. Figma and Miro still exist. The repo simply becomes the place where design decisions and handoffs are recorded. 

There are still open questions too. On a small team without dedicated QA, who formally signs off that acceptance criteria have been met? We are still working that out. 

I’d rather name those edges than pretend the model is finished. 

The honest reframe is that this approach does not eliminate the tracker’s job. 

It absorbs it. 

The consistency Jira enforced for free becomes something you own on purpose. 

For the kind of AI-native work we do, that ownership is the point. 

The repo is already where the work happens. 

So we started asking a simple question: 

What happens if coordination happens there too? 

This operating model is our current answer. 

Not because Git is magical. 

Not because Jira is broken. 

Because operational context now accumulates in one place, and we’re interested in what becomes possible when the people, the artifacts, and the assistants all work from the same source. 

Whether this becomes a broader pattern remains to be seen. 

But after working this way, it is difficult to imagine moving the source of truth back into a system designed primarily to describe the work rather than participate in it. 

The post Pt. 2: Repo-Native Delivery – The Operating Model  appeared first on Robots & Pencils.

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. 

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. 

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 for Part 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. 

The post Pt. 1: Repo-Native Delivery – Why We Ditched Jira for AI Work   appeared first on Robots & Pencils.

Twenty years ago a parent told their kid not to major in art. Ten years ago they said it about English. Five years ago the script tightened to anything that didn’t end in -ology or -engineering. STEM was the moat. STEM was the parachute. STEM was the answer to every dinner-table question your kid was too polite to ask out loud. 

You know how this ends. 

I’ve been watching it end in slow motion for eighteen months. The CS grads I talk to are anxious in a way the comp lit grads aren’t. Not because the comp lit grads have it figured out. They don’t. Nobody does. But they were never promised the floor wouldn’t move. The CS grads were told it was bedrock. Then somebody started writing code at the speed of thought, and the bedrock turned out to be a Jenga tower with a six-week release cycle. 

The irony is thick enough to spread on toast. We trained a generation to speak the language of machines. The machines turned around and learned the language of people. If a screenwriter pitched that arc, the room would tell them to dial it back. 

The company whose name explained everything

I want to tell you a story about a company I ran, because I think it explains what’s actually happening, and what’s coming for the people who were paying attention. 

In 2014, I brought a Canadian agency called Robots & Pencils down to the States. I was CEO of the US operation. We grew thirty-four hundred percent in eighteen months, finished the year as the 35th fastest-growing tech company in the country, and most of the press I gave at the time was about the numbers. The numbers weren’t the story. The name was. 

Robots & Pencils. The name was lifted, more or less, from C.P. Snow’s 1959 lecture on the Two Cultures. Snow’s argument that the sciences and the humanities had drifted into separate languages that could no longer talk to each other, and that the gap between them was the central problem of modern life. He wrote it about Cambridge dining halls. We built it as an agency. 

The robots were the developers. People who could build the thing. The pencils were the designers. People who could see the thing before it existed. Two trades, two trainings, two languages, two halves of any product worth shipping. We had robots. We had pencils. We were good at both. 

And the founder, who was (ironically, beautifully, to his own ongoing amusement) robot #1, was the most insistent voice in the building that good products are always visioned pencils first. You can’t bolt art on at the end. Try it and the seams show forever. The most technical man in the room kept telling the room to start with the drawing. 

Two people who were already the bridge

He didn’t found the company alone. His wife was the pencil to his robot, a brilliant artist, an interior designer with the eye that finds the wrong wall and tells you why, an accountant sharp enough to serve as the company’s CFO. He was the technical man with a love of art he couldn’t fake. She was the artist with the operational backbone most companies wish they could hire. Each of them stretched toward the center. Each of them was already half ampersand before the company had a name. 

That’s why it worked. The two people at the top of the org chart were the bridge they were asking the rest of us to build. You felt it the second you walked in. It pulled in robots who suspected they were also a little bit pencil, pencils who knew they were also a little bit robot, and the people who’d never picked a side at all. The brand wasn’t a logo. The brand was the marriage. 

But the ampersand was the entire reason the company existed. 

The rarest person in any room

You know who I mean. The dev who notices the kerning. The designer who reads the API docs because she actually wants to know what’s possible. The one who drops #picky into a Slack design review without apologizing for it, because they know the small thing is the whole thing. The person who can sit between two rooms that don’t speak each other’s language and translate. Not the words. The intent. They were rare. We’d interview a hundred people and find one. They commanded a premium because the value of a translator scales with the distance between the parties, and the distance between an engineer and a designer in most companies is bigger than the distance between Calgary and the moon. 

The ampersand people weren’t better at either trade. They were the only ones in the room who saw both trades as the same problem from different chairs. They were almost mythological. We named the company after them. 

What AI actually does for the bridge person

Here is what I didn’t see coming, even though I should have. AI doesn’t pick a side. It never had to. It doesn’t just close the gap between the dev and the designer. It closes the gap inside the bridge person, the small and humiliating gap between what they could always see and what they could actually produce. The designer who knew exactly how the API should work but couldn’t write the call. She can write the call now. The dev who saw the right pixel grid but couldn’t move pixels. He can move pixels now. The ampersand always saw both ends of the bridge. Now they can walk it. If Jobs called the computer a bicycle for the mind, AI just strapped rocket engines to the sides. 

You want proof? A 23-year-old amateur mathematician named Liam Price, no PhD, no faculty appointment, no research lab, used ChatGPT to solve an open problem that had been sitting on the shelf for sixty years. Erdős Problem #1196, from primitive set theory. Sixty years. The kind of problem that gets named after the person who posed it because nobody alive could finish it. Price finished it. And then Terence Tao, the Fields Medalist, the person most mathematicians would rank as the best living mind in the discipline, verified the proof and co-authored the resulting paper. A 23-year-old with curiosity and a chatbot sat down at the same table as the greatest mathematician of his generation. Not because AI solved the problem for him. Because AI let him hold the conversation long enough to solve it himself. That’s the ampersand. That’s curiosity with tooling that doesn’t punish you for not having the right letters after your name. 

The bridge people are about to multiply. Not because the trait gets more common. That takes generations, and curiosity in two directions has never been on any roadmap I’ve ever seen. But the trait finally has tooling that doesn’t punish it for refusing to specialize. For thirty years we paid the ampersand person less because they weren’t “really” a developer or “really” a designer. We tolerated them because they made the meetings work. They are about to inherit the building. 

And the lesson runs wider than design and code, because the ampersand was never really about design and code. The ampersand is about being curious in two directions at once. It’s about being the kind of person who refuses to pick a side because they can’t stand to leave the other side ignorant. That’s not a job description. That’s a humanities education. 

Read carefully. Argue clearly. Hold a contradiction without flinching. Care about the answer even when nobody’s grading you. Do the hard thing quietly. Take care of the person next to you before you take care of yourself. Carry two trades at once and a third in reserve. Say what you mean and mean what you say. It doesn’t sound like much. It also doesn’t fit in a job code, which is why we’ve been quietly defunding it for forty years. It didn’t return on a single-year horizon, and the only people who tried to defend it sounded like they were defending themselves. 

I’ll tell you where I learned all of it, because it wasn’t school. It was my parents and the people they surrounded us with. A father who came up through the Green Berets and ran a house on the principle that you say what you mean and you mean what you say. A mother and a community who treated curiosity as a chore you didn’t get to skip. Nobody handed me a syllabus on holding a contradiction. I watched the adults around me do it at the dinner table. I graduated into the internet in 1985 and was running an ISP a decade later. That sharpened the tools. The tools came from home. 

That’s the part the system can’t replicate and won’t admit. The ampersand is mostly raised, not taught. The people who saw this moment coming were mostly the ones we wouldn’t fund. And the ones who can step into it now were mostly raised by people who didn’t need a funding line to know it mattered. 

The skill with a 25-year half-life

Framework knowledge has a half-life of about two and a half years. That’s IBM’s number for specialist technical skills, and it tracks with what the National Academy of Engineering has been saying for twenty years. By contrast, the half-life of a humanities education runs closer to twenty-five. The argument structure Aristotle taught is still the argument structure that wins. The people who can build and fix the machine will be needed for as long as there’s a machine. The play isn’t picking a side. It’s picking one discipline that ages well and one that compounds fast, and refusing to let either atrophy. 

Walk into a room where the pencils and the robots are really cooking and you can feel it through the floor. The designers sketch faster than the engineers can build. The engineers build faster than the designers can sketch. The ampersand is at the whiteboard turning the sketch into a system and the system into a sketch, and everybody in the room is operating one cognitive notch above where they could operate alone. That hum used to be the rarest sound in tech. We’re about to hear it everywhere. In classrooms, in clinics, in non-profits, in offices that have been quietly dying for a decade because the bridge person never showed up. 

Don’t mistake this for triumphalism. The reversal doesn’t make the humanities grad rich and the CS grad poor. It rearranges who has leverage, which is a different and harder problem. The CS grads who pair their craft with the human stuff, curiosity in two directions, care for the person on the other side of the screen, are going to be fine. The humanities grads who learned to type sentences but never learned to sit with a real problem until it broke? They’re going to wash out the same as anyone. The credential never saved anybody. The skill underneath the credential is the only thing that matters now. 

What’s coming is a world where you need both hands. The robot hand and the pencil hand. The technical and the human. The thing the machine can amplify and the thing the machine cannot replace. People who learned only one are about to find themselves doing half a job. People who learned both, the ampersands, the bridge people, the curious-in-two-directions people, are about to find the assignment finally suits them. 

The career advice parents need to hear in 2026

I’ll say something with an edge, because I have watched too many parents push too many kids in the wrong direction and I am out of polite ways to put it. Stop telling your daughter to pick something “practical.” There is nothing practical about training her for a job description that will be rewritten before she graduates. Tell her to chase the thing she is actually curious about, and tell her to learn the tools that scale curiosity. That is the practical answer in 2026. Everything else is nostalgia for a stability that was always a marketing slogan. 

And tell her to find the room. Find a university, a community, a circle that’s already wired for curiosity in two directions. Humanities and sciences sitting at the same table, AI amplifying both, and credentials that still translate into workforce currency on the other side. Skills, capabilities, and a degree. Not one or the other. Humble plug, because it would be dishonest not to say it: that’s exactly what we’re building at Maryville. An achievement architecture for all of them. Robots, ampersands, and pencils. AI amplifying each one’s curiosity and capabilities. We’re about to show, not tell, what that means. Stay tuned. 

The ampersand was always the symbol of the company because it was the symbol of the work. Two trades, one person, one connector character holding the whole sentence together. It was never decoration. It was the structure. 

The robots are getting better. The pencils are getting better. But the people who can hold both, who can be technical without losing their humanity, who can be human without abandoning the craft, those people are about to inherit the moment. The ones we underpaid for thirty years because we couldn’t fit them in a column. 

Strive to be a little ampersand. Not just the robot. Not just the pencil. The character in the middle that connects them. 

That’s the job now. And it’s the abstract of every job that comes after it. 

The team Phil wrote about? That’s us. Robots & Pencils has been building at the intersection of technical and human since day one. Request an AI briefing and see what that means for your organization.

About Phil Komarny

Phil Komarny, an award-winning executive, national thought leader, and Chief Future/AI Officer at Maryville University. He led Robots & Pencils as CEO in 2014 and 2015. It’s clear he never stopped thinking about what our name meant. Read more articles by Phil.

Key Takeaways

1. The “ampersand person” is someone curious in two directions at once — technical and human — and they have always been the most valuable person in the room.
2. AI doesn’t replace the bridge person. It closes the gap between what they could always see and what they could actually produce.
3. Framework knowledge has a half-life of roughly two and a half years. The skills underneath a humanities education run closer to twenty-five.
4. For thirty years we underpaid the generalist because they didn’t fit a job code. That’s about to change.
5. The practical career move in 2026 is pairing one discipline that ages well with one that compounds fast — and refusing to let either atrophy.

FAQ

What is the ampersand person? Someone who refuses to specialize in just one direction. They can sit between two rooms that don’t speak each other’s language and translate not the words, but the intent.

Why is the Robots & Pencils name significant? The name draws on C.P. Snow’s 1959 Two Cultures lecture — the idea that the sciences and humanities had drifted into separate languages. Robots represented the builders. Pencils represented the visionaries. The ampersand between them was always the point.

How does AI change things for generalists? AI closes the gap between what bridge people could always see and what they could actually produce. The designer who knew how the API should work can now write the call. The developer who saw the right pixel grid can now move pixels.

Is a humanities education still worth it? According to Phil Komarny, yes — more than ever. The argument structure Aristotle taught still wins. The credential doesn’t save anyone, but the skill underneath it compounds in a way technical specialization alone no longer does.

What should parents tell their kids about careers in an AI world? Stop pushing “something practical” defined by yesterday’s job market. Tell them to chase what they’re genuinely curious about and learn the tools that scale curiosity. That is the practical answer in 2026.

The post The Ampersand: Generalists in the AI Era appeared first on Robots & Pencils.

AWS releases generative and agentic AI services faster than most enterprises can deploy them, and that gap is widening every quarter they wait. In June, the Applied AI Engineering Partner will be on the ground at three AWS Summit events, ready to sit down with enterprise and public sector leaders who are done with pilots and ready to take generative and agentic AI live.

The AWS Summit series is where enterprise technology leaders gather to see what is possible on AWS. As an AWS Advanced Tier Services Partner and one of 11 inaugural AWS Pattern Partners selected from the AWS Partner Network, Robots & Pencils is the nimble, high-velocity alternative to traditional global systems integrators. Every engagement starts with the outcome the client needs and earns it with evidence. Velocity Pods, Robots & Pencils’ atomic delivery units, are small teams of senior practitioners that take AI solutions from concept to production on Amazon Bedrock and Amazon Bedrock AgentCore in weeks, compared to 6 to 12 months with a traditional systems integrator. 

“AWS has built the full-stack agentic AI infrastructure. The technology is ready. What we do is put it to work fast,” said Adrian Bird, VP of AWS Partnership at Robots & Pencils. “We work with your teams to build the business architecture that takes enterprise AI live before the next board meeting.”

“Enterprises don’t need another aircraft carrier full of consultants in the AI era,” said Jeff Kirk, EVP of Applied AI at Robots & Pencils. “They need a speedboat, a forward deployed team small enough to be surgical, senior enough to build for scale with, and fast enough to prove ROI before the next budget cycle.”

What the Robots & Pencils Builds on AWS 

Agentic AI with AWS is the core of the work. AI agents built on Amazon Bedrock and Amazon Bedrock AgentCore that work alongside human teams in live not in a sandbox. 

Cloud Modernization gets organizations off aging infrastructure and onto a serverless, AWS-native foundation built to scale, not just to run. 

Cloud and AI App Development is where engineers and creatives build in the same room, producing cloud-native applications with generative AI in the architecture from day one. 

For enterprise and public sector teams attending any of the three summits, the Robots & Pencils team is ready to talk. 

Schedule time with the Robots & Pencils team:  

• AWS Summit Los Angeles, June 10 

• AWS Summit New York City, June 17 

• AWS Summit Washington, D.C., June 30 – July 1 

The post Robots & Pencils Hits Three AWS Summits in June with One Message: It’s Time to Launch and Scale AI appeared first on Robots & Pencils.

EXPO XXI is a short ride from the center of Warsaw, and on a May morning you can feel the conference before you see it. The queue outside was long but moving fast. Hoodies, lanyards, laptop bags. The crowd skewed more senior than you might expect at a free regional event.  

Our plan was deliberate. Show up early, split the agenda, cover more ground in parallel, regroup over coffee, and most importantly, validate our approach.  

Robots & Pencils team members in attendance, from left to right: Stanislav Makar, Rostyslav Volskyi, and Bohdan Popovych. 

Agentic AI is the AWS Headline. 

The opening keynote made one thing clear. Agentic AI is the organizing thesis for everything AWS is building in 2026. 

Three names anchored the story. Kiro, the agentic IDE that got a fresh push at re:Invent 2025, featured prominently with its spec-driven development model, sequenced task generation, and agents that produce tests alongside code. Nova 2, the model powering more of the AWS AI surface, continues its region-by-region rollout. AWS Transform, their modernization platform for mainframe, VMware, and .NET workloads, framed as the agentic path into enterprise legacy systems. 

Real customer stories on stage. Real numbers. Real screenshots. The European Sovereign Cloud and the EMEA AI Hub got dedicated time, which landed well with the Warsaw audience. The framing was consistent throughout: the shift from AI tools you prompt to AI agents that reason, plan, and act is underway. The question for builders is how you instrument, evaluate, and trust what those agents do. 

That question got a very good answer in the next session. 

The Session That Landed: AgentCore Evaluations in Production 

Right timing matters at a conference, and the AgentCore deep-dive landed at exactly the right moment. AWS spent the spring pushing AgentCore Evaluations hard. It went GA on March 31, 2026, and the Warsaw session put it directly in front of European builders. 

The plain-language version of what it does: a managed service that continuously monitors agent quality against real production traces, not just test suites. You are shipping agents. You need to know they work. Handing someone a scorecard you hand-rolled for each project is not a sustainable answer. This is. 

The built-in evaluators cover what matters in production: 

• Correctness. Did the agent get the answer right? 

• Helpfulness. Was the response useful to the person asking? 

• Tool selection accuracy. Did the agent pick the right tool for the step? 

• Safety. Did anything in the output violate policy? 

• Goal success rate. Did the multi-step task complete? 

• Context relevance. Did the retrieved context match the question? 

On top of those you can configure custom evaluators. LLM-as-judge with your own prompt and model, or code-based evaluators running on Lambda. The same framework handles hallucination detection and JSON schema validation without forcing two different toolchains. 

The detail that made us lean forward: full OpenTelemetry compatibility. The evaluator scores flow into existing dashboards alongside session count, latency, token usage, and error rates. You can alert on agent quality the same way you alert on a CPU spike. 

For anyone building agents on behalf of enterprise customers, this solves the credibility problem. “How do you know it works in production” is no longer a hand-waving moment. 

The Best Conversation Happened at the Espresso Machine 

One of the more useful exchanges of the day started while waiting for coffee. 

AWS set up a cloud-ordered espresso bar on the expo floor. You scanned a QR code, placed your order in a small web app, and the espresso machine queued it. When the drink was ready, the screen showed your name. No line. No barista small talk. Beautifully on-brand for a cloud event, and genuinely better than the alternative. 

While we waited, a conversation started with a Senior Solutions Architect at AWS. It turned into one of the most useful exchanges of the day. The topic was whether Lambda is a credible runtime for agentic workflows. The honest answer is: it depends on whether you have state. 

An agent is not a request and a response. It is a long, branching workflow with LLM calls, tool invocations, and occasional human-in-the-loop steps. Lambda durable functions, which AWS shipped in late 2025 and has been shaping for agentic use cases since, address this directly. Each LLM call and each tool invocation becomes a checkpointed step inside a single Lambda. If execution times out mid-loop, the next invocation replays from the last checkpoint and skips completed steps. No Step Functions wiring. No custom state store. No DIY replay logic. The orchestration lives in the function code, in the language you already use. 

The Java SDK went GA in April 2026. Durable functions are now available in sixteen additional regions. 

The Best Hour of the Day: Knowledge Graphs 

Two talks on knowledge graphs stood out as the strongest technical content of the summit. The first was delivered by Dmytro Romantsov, Senior SRE at Miro, on their internal AI agent built over an organizational graph. The talk was technically dense and honest: he walked through what failed before the team settled on a graph-backed architecture, what the graph actually contains, how updates flow into it, and where the approach delivers measurably better results than the pre-graph baseline. 

After the session, we walked over to talk to him. Small-world moment: we share a first language, switched off English immediately, and the conversation opened up. The core thesis from both the talk and the follow-up conversation was consistent. Enterprise AI agents are only as good as the organizational knowledge they can reason over. A graph gives that knowledge structure, updateability, and query depth that flat retrieval cannot match. That is not a new idea, but watching it validated independently at Miro’s scale makes the argument more concrete. 

The second strong graph talk came from an SLB engineer in DEV207, on context graphs for explainable AI agents. The framing that stuck: the difference between a state clock and an event clock. Most pipelines today reflect the current state of a system. A context graph that also captures decision events can answer “why did this happen, and in what order.” That is the kind of explainability enterprise buyers are starting to require as agents move from pilot to live. 

Asking Honest Questions About AWS Transform 

The AWS Transform booth was busy. The team arrived with a direct question about IBM RPG support and walked through the answer methodically with a Solutions Architect for Migration and Modernization at AWS. 

The most telling moment was watching an AWS specialist type the same question into their own tool in front of us. The answer came back: yes, with limitations, followed by pages of caveats. Informative in its own way. 

The bottom line is that AWS Transform is production-grade for COBOL, Java-to-JavaScript migrations, VMware modernization, and mainframe workloads. RPG support is real but not ready for complex production use cases. We left with clarity on where the tool genuinely shines and where the right path is a combination of other tools and hand-rolled pipelines. That kind of honest answer is the second-best outcome at a conference. It tells you your reasoning was sound. 

The VMware migration angle, by contrast, is genuinely strong. Broadcom’s license changes are creating real urgency for customers running on VMware infrastructure. Worth flagging for relevant engagements. 

The Compute Thesis: AWS is Sizing Infrastructure for Self-Managed AI 

A theme ran underneath the agentic-AI headline all day: AWS is provisioning compute to match the shape of AI demand, and the demand right now for these kinds of workloads is high. 

Two sessions made the same point from opposite ends of the price spectrum. Comarch walked through a real migration from x86 to AWS Graviton-based instances, with meaningful cost reductions and measured performance gains. The honest part of their talk: Graviton is not a flag flip. If you have native code, JNI bindings, or JIT-tuned hotspots, you pay for the migration before you see the savings. 

On the other end of the spectrum: Meta’s agreement to deploy AWS Graviton processors at scale, starting with tens of millions of Graviton cores, announced ten days before the summit and explicitly framed around CPU-intensive agentic AI workloads — real-time reasoning, code generation, and multi-step task orchestration. 

For Robots & Pencils, this opens a third option alongside Bedrock and direct provider APIs. For clients with data-residency constraints, predictable high-volume workloads, or smaller open-weight models where managed-API margins make self-managed attractive, the playbook is now well-documented and accessible. Independent benchmarks on Llama 3.1 8B have Graviton4 delivering roughly 2x the tokens per dollar of comparable x86 options for that model class. 

A Practitioner’s Checklist for 2026 

The session that generated the most useful signal for client-facing conversations was DEV209, delivered by Tomasz Dudek, Data and AI Team Lead at Chaos Gears and an AWS Machine Learning Hero. The premise was simple: AI has been mainstream for over three years. He has watched hundreds of Amazon Bedrock projects pass through his hands. Most near-failures trace back to a small set of repeatable mistakes. 

The talk was the inverse of a vendor pitch. Here is exactly how teams stall before the first line of code. Here is what to do instead. He closed with 13 numbered tips for approaching AI projects in 2026. The final line: “Have evals, really.” 

It was good to hear a practitioner at that level land on the same conclusions we have been operating on. The teams doing this work at scale are converging on the same principles, and the list mapped closely to how we already approach agent quality on client engagements. Confirmation from that angle is worth having. 

The Parts That Were Just Fun 

Not everything at a summit is a session worth writing home about. But a few moments, in addition to the Serverlesspresso bar, which was cool enough to warrant a second mention, stood out for the right reasons. 

The AWS Drive Your Data Formula 1 simulator was exactly what it looked like: two Fanatec rigs, full wraparound LED screens, a Canada time-trial, and a results board you could compete on. The pitch underneath was real telemetry and lap analytics. The booth’s job was to draw a crowd, and it absolutely did. The team took turns. 

And the Ukrainian-speaking community was well-represented at this summit. Several familiar-sounding conversations happened in unexpected corners of the expo. That part mattered. 

What the Day Confirmed 

The most useful thing a conference can do is sharpen your picture of where the tools are today versus where they are heading. Warsaw 2026 did that well. 

Agentic AI is no longer a roadmap commitment from AWS. It is the organizing logic of everything they showed. Agent evaluation infrastructure is production-ready and instrumented the way mature engineering teams expect. The compute story has matured to a point where self-hosting is a genuine option for the right workloads, not just a theoretical one. Knowledge graphs as a foundation for enterprise AI agents are getting independent validation at scale. And the practitioners who have been doing this work longest are converging on the same principles around evaluation, quality gates, and shipping agents that are honest about what they know. 

None of that surprised us. All of it was good to see confirmed. 

Warsaw 2026 delivered real technical depth on agentic AI, agent evaluation, and knowledge graphs. The team went in with specific questions and came back with sharper answers, a few useful new contacts, and a strong argument for cloud-ordered coffee at the next internal engineering day. 

Robots & Pencils is an AWS Advanced Tier Services Partner and AWS Pattern Partner. Request an AI Briefing today. 

Written by Bohdan Popovych: Robots & Pencils Ukraine Engineering Manager, Rostyslav Volskyi: AWS Certified Solutions Architect and Amazon Web Services Developer, and Stanislav Makar: AWS Certified Solutions Architect – Professional.  

The post AWS Summit Warsaw 2026: What We Saw, Who We Met, and What It Confirmed  appeared first on Robots & Pencils.

Robots & Pencils, an applied AI engineering partner known for high-velocity delivery and measurable business outcomes, today announced it has achieved AWS Advanced Tier Partner status. The designation marks a significant milestone in the company’s continued growth, delivering production-grade systems on AWS for enterprise organizations.

Explore how Robots & Pencils delivers applied AI and cloud-native systems built to operate at enterprise scale. 

AWS Advanced Tier Recognition Reflects Production-grade Delivery at Enterprise Scale

AWS Advanced Tier Partner status recognizes organizations with demonstrated depth in AWS delivery, technical expertise, and customer success at scale. Partners at this level consistently design, build, and operate secure, resilient, and scalable systems running in production. Robots & Pencils earned this designation through sustained enterprise delivery, a strong bench of AWS-certified engineers, and real-world workloads running on AWS.

A High-Velocity Alternative to Traditional Global Systems Integrators

Robots & Pencils operates as a nimble alternative to traditional global systems integrators, pairing AWS-native architecture with a relentless focus on velocity and impact. Small, senior, highly focused teams move quickly from idea to execution, delivering production-ready systems that create value early and improve continuously through real-world learning.

“Our AWS Advanced Tier designation continues to build on strong momentum as we strengthen our relationship with AWS,” said Len Pagon Jr., Chief Executive Officer of Robots & Pencils. “In December, we were selected as one of 11 AWS Partners out of more than 190,000 to join the new Pattern Partner program. In January, we launched our Bellevue, WA Innovation Center next door to AWS HQ to work closely with the AWS GenAIIC team. Now, as an AWS Advanced Tier Services Partner, we have access to additional AWS funding for proofs of concept and substantial resources to support our clients.”

Building and Operating Generative and Agentic AI Systems that Scale

Enterprise leaders continue accelerating modernization and AI initiatives that demand speed, reliability, and operational maturity. 

AWS Advanced Tier status signals that Robots & Pencils brings disciplined execution and rapid iteration to move confidently from strategy to production and scale. Clients gain earlier insight, reduced delivery risk, and steady progress aligned to clear business outcomes.

“Enterprises are moving quickly toward generative and agentic AI systems that operate as an enablement layer of their business,” said Jeff Kirk, Executive Vice President of Applied AI at Robots & Pencils. “AWS provides a powerful foundation, and our role is to design and deliver AI systems that integrate securely, perform reliably, and scale with confidence. Advanced Tier recognition affirms our ability to move AI from ambition into production.”

Certified Talent and Engineering Discipline Behind AWS Advanced Tier Recognition

The AWS Advanced Tier recognition also reflects the company’s investment in certified talent, security discipline, and operational excellence.

“AWS Advanced Tier status is earned through consistency, accountability, and a deep commitment to craft,” said Nicholas Waynik, Vice President of Engineering at Robots & Pencils. “Our engineers invested the time to master the platform, earn the certifications, and apply that knowledge to systems running in production. This recognition reflects the standards they hold themselves to every day and the trust our clients place in their work.”

Enterprise-ready AI Architectures Delivering Impact Across Industries

Robots & Pencils also holds AWS Pattern Partner recognition, highlighting its strength in delivering repeatable, enterprise-ready architectures for applied AI and intelligent systems. This capability complements Advanced Tier status by reinforcing architectural leadership alongside delivery maturity, while maintaining a clear focus on execution that performs in production.

Robots & Pencils delivers application modernization, cloud-native product development, data platforms, and AI-enabled systems on AWS across Consumer Products and Retail, Education, Energy, Financial Services, Healthcare, and Manufacturing. These solutions support regulated environments, high-growth digital products, and complex enterprise ecosystems where reliability and scalability matter every day.

Request an AI briefing to evaluate how applied AI can deliver velocity and impact within your organization.

The post Robots & Pencils Achieves Amazon Web Services (AWS) Advanced Tier Partner Status appeared first on Robots & Pencils.

The model works. It predicts churn beautifully. It just doesn’t prevent it. 

This might seem like an implementation problem. Maybe the marketing team didn’t act on the predictions quickly enough, or the retention offers weren’t compelling enough. But the issue runs deeper than that. The problem starts with how the project was framed in the first place.

When Churn Prediction Becomes Theater 

Here’s what prediction theater looks like in practice: Your churn model flags a high-risk customer on Monday morning. The prediction appears in a dashboard. Someone from marketing reviews it during Thursday’s retention meeting and adds the customer to next week’s email campaign. The customer cancels their subscription on Tuesday. Five days after the model predicted it. Three days before marketing acted on it. The model performed perfectly. It predicted an outcome. But prediction without intervention is just expensive surveillance. 

This pattern repeats because organizations optimize for the wrong outcome: prediction accuracy instead of churn reduction. Accuracy is measurable, improvable, and requires no workflow changes. You can plot ROC curves and present F1 scores in quarterly reviews. Prevention requires rebuilding operations across marketing automation, customer service systems, and approval workflows.

Why Accurate Churn Prediction Rarely Changes Outcomes 

The constraint is intervention capacity, not model accuracy. Improving your model from 85% to 87% accuracy doesn’t mean anything if you can only act on 20% of the predictions. When intervention capacity is the bottleneck, marginal accuracy improvements deliver zero business value. It’s like building a faster fire alarm when what you actually need is a sprinkler system. For many retailers, the real constraint shows up in the approval process. Attractive retention offers often require VP sign-off, which can introduce multi-day delays and make timely intervention difficult.

Prevention requires event-driven architecture, where systems respond immediately to customer actions within seconds or minutes instead of waiting for batch processing cycles that run nightly or weekly. When a customer shows churn signals like cart abandonment, a subscription cancellation attempt, or declining engagement, the system must detect the signal, assess the situation, and intervene automatically while the customer is still engaged. This is a very different approach from prediction systems that generate reports for human review.

The Architecture of Churn Prevention 

Netflix offers one of the most familiar examples of what prevention architecture looks like in practice. Looking at how their system works makes the four components of effective prevention clear. 

Signal detection: The system continuously monitors viewing behaviors, like declining watch time, increased browsing without watching, and longer gaps between sessions. These signals indicate churn risk before the customer consciously decides to cancel.

Intelligence layer: When signals trigger, the system calculates subscriber lifetime value, checks recent engagement patterns, and determines if intervention is warranted. Not every signal gets an intervention. The system only acts when the data suggests it will work.

Automated intervention: Within seconds, the recommendation engine adjusts what content appears, emphasizing shows with high completion rates for similar subscribers. This happens without dashboard review or marketing approval, allowing the system to act while the customer is still engaged. 

Outcome measurement: The system tracks whether the interventions worked. Did the subscriber watch the recommended content? Did engagement increase? The algorithm continuously learns which recommendations retain which subscriber segments.

This automated prevention architecture contributes to Netflix maintaining an industry-leading monthly churn rate hovering between 1-3% over the past two years, well below the streaming industry average of approximately 5%. Over 80% of content watched on Netflix comes from these algorithmic recommendations. The distinction is critical: Netflix built a model to predict which subscribers might leave and the systems that automatically present compelling reasons to stay at the moment of decision. 

This same prevention architecture applies just as effectively to physical products. Customer signals still appear in real time through behaviors like cancellation attempts, delayed reorders, or changes in purchase patterns. Systems can evaluate context such as purchase history and customer value, decide whether intervention makes sense, and respond immediately with relevant offers, guidance, or incentives. By measuring outcomes and learning which responses work for different customers, physical product businesses can intervene at the moment decisions are forming rather than after churn has already occurred. 

What Makes Churn Prevention Smart 

Problems emerge when components are skipped. A subscription box retailer might implement automated cancellation prevention while leaving out the intelligence layer, the business logic that prevents gaming. Without assessing customer value, limiting offer frequency, or recognizing behavior patterns, every customer who clicks ‘cancel’ receives the same discount. The system works on the surface, but over time it teaches customers how to exploit it. What started as a retention tactic turns into a habit, margins erode, and prevention stops doing the work it was meant to do. 

This gaming scenario raises the immediate question marketing teams ask: “Doesn’t automation mean losing brand control?” Not if the intelligence layer encodes your judgment as guardrails. No discount over XX%. No offers conflicting with active campaigns. VIP customers (top X% LTV) escalate to human review before any automated intervention. Win-back offers only after a defined cooling period. Your brand standards become executable rules that prevent the system from going rogue, while still acting faster than manual review workflows. 

Operational Readiness Comes Before Modeling Sophistication 

Before building a churn model, map the complete intervention workflow: 

• How will predictions trigger actions across channels? (If the answer involves a weekly dashboard review, you’re building a prediction theater.) 

• What systems enable real-time personalization? (Can you respond when customers show churn signals?) 

• Who has the authority to modify customer treatment dynamically? (Automated systems with guardrails, or manual approval workflows? 

• What is the acceptable latency between prediction and intervention? (Minutes? Hours? Days?) 

Clear answers to these questions determine readiness. Building prediction models without intervention infrastructure creates sophisticated systems that generate insights teams cannot act on at retail speed. 

Building AI Systems That Act Before Customers Leave 

The goal is simple. Prevent customers from leaving in the moment when they are making that decision.  

The shift from prediction to prevention requires AI-powered systems that can detect signals, assess customer value, and execute personalized interventions automatically and without human review delays. This  works when you encode human judgment into systems that can act at machine speed. The intelligence layer (LTV assessment, discount frequency limits, pattern detection, and margin guardrails) separates effective prevention from expensive automation theater. 

Here’s how to start: 

• Step 1: Choose one high-value churn segment (not the largest, but the one where retention has the highest dollar impact). 

• Step 2: Map signal to intervention: Document every step from customer signal to executed action. Where does latency creep in? 

• Step 3: Cut one manual approval step. If every offer needs manual sign‑off, you eliminate any chance of quick action. Let AI automate and accelerate that step. 

• Step 4: Measure what matters: Track retention rates and customer lifetime value, not model accuracy. 

The technical challenge of predicting churn is no longer the constraint. Durable advantage now comes from leaders who design organizations that act, decisively and automatically, at the moment of customer decision.

The pace of AI change can feel relentless with tools, processes, and practices evolving almost weekly. We help organizations navigate this landscape with clarity, balancing experimentation with governance, and turning AI’s potential into practical, measurable outcomes. If you’re looking to explore how AI can work inside your organization—not just in theory, but in practice—we’d love to be a partner in that journey. Request an AI briefing. 

Key Takeaways 

• Architecture determines outcomes. Event-driven systems enable real-time intervention, while batch systems document churn after it happens. 

• Intervention capacity creates the true bottleneck. Automated prevention systems scale decision-making with the customer base. 

• The intelligence layer makes prevention smart. LTV assessment, discount limits, and margin guardrails prevent gaming while maintaining brand control. 

FAQ 

What’s the difference between churn prediction and churn prevention? 
Churn prediction identifies which customers may leave. Churn prevention intervenes automatically to change customer behavior before they leave. Prediction relies on analytics. Prevention relies on decision automation and real-time execution. 

Why do accurate churn models fail to reduce churn rates? 
Prediction accuracy creates no value without intervention capacity. When models identify more at-risk customers than teams can act on, marginal accuracy delivers zero impact. 

What makes a churn prevention system different architecturally? 
Prevention systems use event-driven architectures that automate the full loop: signal detection, intervention selection, execution, and outcome measurement. 

How should retail organizations measure churn AI success? 
Track retention improvement, customer lifetime value growth, intervention response rates, and cost per retained customer. Model accuracy measures technical quality. Business impact requires retention metrics. 

The post Your Churn Model Works Perfectly. So Why are Your Customers Still Leaving?  appeared first on Robots & Pencils.

Under time pressure, people do what people always do. They ask around. They rely on memory. They make the best call they can with what they recall. 

That’s the situation many organizations quietly operate in. Field teams losing meaningful time every shift just trying to locate procedures. Compliance leaders increasingly uneasy with how often answers came from tribal knowledge. The documents exists. Access technically exists. What’s missing is usable context. 

When Policy Knowledge Exists but Usable Context Does Not 

The obvious move is to build a RAG (Retrieval-Augmented Generation) assistant. 

That’s where the real work begins. 

What we didn’t fully appreciate at first was that this wasn’t a retrieval problem. It was a context construction problem. 

The challenge wasn’t finding relevant text. It was deciding what the model should be allowed to see together. In hindsight, this had less to do with RAG mechanics and more to do with what we’ve come to think of as context engineering: deliberately designing the context window so the model sees complete, coherent meaning instead of fragments. 

Where the “Obvious” Solution Fell Short 

We didn’t start naïvely. We explored modern RAG patterns explicitly designed to reduce context loss. Parent–child retrieval, hierarchical and semantic chunking, overlap tuning, and filtered search strategies. These approaches are widely used in production for structured documents, and for good reason. 

They did perform better than baseline setups. 

But for these policy documents, the same failure mode kept showing up. 

Answers were fluent. Confident. Often almost right. 

Procedures came back incomplete. Steps appeared out of order. Exact wording, phone numbers, escalation paths, timelines – softened or blurred. And when the model couldn’t see the missing context, it filled the gaps with something plausible. 

Why “Almost Right” Answers Are Dangerous in Compliance & Procedural Work 

At that point, the issue was no longer retrieval quality. 

It was context loss at decision time. 

A procedure isn’t just information. It’s a sequence with dependencies. Even when parent documents were pulled in after similarity-based retrieval, the choice of which parent to load was still probabilistic, driven by embedding similarity rather than document structure. 

In compliance-heavy environments, “coherent but incomplete” is an uncomfortable place to land. 

This became the line we couldn’t ignore: 

Chunking isn’t a neutral technical step. It’s a design decision about what context you’re willing to lose and when. 

Chunking Is a Design Choice About Risk 

Most modern RAG systems correctly recognize that context matters. Parent–child retrieval and hierarchical chunking exist precisely because naïve fragmentation breaks meaning. 

What many of these systems still assume, though, is that similarity-first retrieval should remain the primary organizing principle. 

Why Similarity-First Retrieval Breaks Policy Logic 

For many domains, that’s a reasonable default. For large policy documents, it turned out to be the limiting factor. 

Policy documents reflect how institutions think about responsibility and risk. They’re organized categorically. They use deliberate, constrained language like – within 24 hours, contact this number. And their most important procedures often span pages, not paragraphs. 

When that structure gets flattened into ranked results, even if parent sections are expanded later – similarity still decides which context the model sees first. 

And when surrounding context disappears, the model does what it’s trained to do: it narrates. 

Not recklessly. Not maliciously. 

Just helpfully. 

That was the subtle failure mode we kept encountering – the system becoming a confident narrator when what the situation required was a careful witness. 

Naming the Problem Changed the System 

Once we framed this as a context engineering problem, the architecture shifted. 

Instead of asking, “How do we retrieve the most relevant chunks?” we started asking a different question: 

What does the model actually need to see to answer this safely and faithfully? 

That reframing moved us away from similarity-first defaults and toward deliberate context construction. 

In retrospect, this wasn’t a rejection of modern RAG techniques. It was a refinement of them. 

The Design Decisions That Actually Changed Outcomes 

Once the problem was named clearly, a small set of design decisions emerged as disproportionately impactful. None of these ideas are novel on their own. What mattered was how they were combined. 

Classify First, Then Retrieve 

Before touching the vector store, the system classifies what the user is asking about. An LLM determines the query category and confidence level. 

When confidence is high, full pages from that category are loaded via metadata lookup – no embedding search required. 

When confidence is low, the system falls back to chunk-based vector search, not as the default, but as a safety net for ambiguous or cross-cutting questions. 

You can think of this as parent–child retrieval where the parent is selected deterministically by intent, rather than probabilistically by similarity. 

Dual Document Architecture 

Location-specific documents were separated from company-wide documents, each with its own taxonomy. “What’s the overtime policy?” and “Where’s the emergency exit?” require fundamentally different context. 

Domain-Specific Taxonomy 

Categories were designed to align with how policy documents are actually authored, not how users phrase questions. Categories were assigned at upload time, not query time, making retrieval deterministic and fast. 

Token-Aware Page Loading 

Even full pages can exceed context limits. Dynamic loading prioritizes contiguous pages and stops when the token budget is reached. The tradeoff was intentional: complete procedures beat partial matches. 

The Big Lesson: Context Is the Real Interface Between Policy and AI Judgment 

Context is easy to treat as plumbing – important, but invisible. 

In reality, context is the interface between an organization’s reality and a model’s generative capability. 

So yes, modern RAG techniques matter. 

But in systems built around policy, safety, and compliance, the sequence in which they’re applied matters more than we usually admit. Not because it helps the model answer faster but because it helps the model answer without taking liberties. 

If you’re building RAG for policy, compliance, or any domain where fidelity matters more than speed, it’s worth pausing to ask, “What context actually needs to be present?” That question alone can lead to systems that are simpler and ultimately more trustworthy than expected. 

It’s also worth noting: These patterns are particularly relevant in environments where data residency or deployment constraints limit the use of cloud-hosted models. That constraint sharpened every design decision, and it’s a story worth exploring separately. 

The pace of AI change can feel relentless with tools, processes, and practices evolving almost weekly. We help organizations navigate this landscape with clarity, balancing experimentation with governance, and turning AI’s potential into practical, measurable outcomes. If you’re looking to explore how AI can work inside your organization—not just in theory, but in practice—we’d love to be a partner in that journey. Request an AI briefing. 

Key Takeaways 

• Context engineering determines whether RAG systems act as faithful readers or confident narrators. 

• In policy and compliance domains, retrieval order matters more than retrieval score. 

• Chunking decisions shape what the model can understand together, and therefore what it can answer safely. 

• Similarity-first retrieval works well for discovery, but procedural fidelity requires deterministic context selection. 

• Classifying intent before retrieval creates more trustworthy outcomes than relying on embeddings alone. 

• Systems designed around full procedures outperform systems optimized for partial relevance. 

• Local, open-source LLM deployments amplify the importance of disciplined context construction. 

FAQs 

What is context engineering in RAG systems? 

Context engineering is the deliberate design of what information an LLM sees together in its context window. It focuses on preserving complete meaning, sequence, and dependencies rather than optimizing for similarity scores alone. 

Why does retrieval order matter for policy documents? 

Policy documents encode responsibility, timelines, and escalation paths across sections. When retrieval order fragments that structure, models produce answers that sound correct while missing critical steps or constraints. 

Why do RAG systems hallucinate in compliance scenarios? 

They usually do not hallucinate randomly. They infer missing steps when surrounding context is absent. This happens when procedures are split across chunks or retrieved out of sequence. 

When should similarity-based retrieval be avoided? 

Similarity-based retrieval becomes risky in domains where sequence and completeness matter more than topical relevance, such as safety procedures, regulatory policies, and escalation protocols. 

How does classifying before retrieval improve accuracy? 

Intent classification allows systems to load entire, relevant sections deterministically. This ensures the model sees complete procedures rather than fragments selected by embedding proximity. 

Is this approach compatible with modern RAG architectures? 

Yes. It refines modern RAG techniques by sequencing them differently. Vector search becomes a fallback for ambiguity rather than the primary organizing principle. 

Does this approach require proprietary models or cloud infrastructure? 

No. The system described was built using open-source LLMs running locally, which increased the importance of careful context design and eliminated data exposure risk. 

The post Context Engineering is the Part of RAG Everyone Skips   appeared first on Robots & Pencils.

There is a simple truth in basketball: when someone claims they can dunk, you do not want their biography. You want to see them take off, rise above the rim, and throw it down. Until the ball goes through the hoop, everything else is just pregame chatter. 

Traditional business pitches are no different. Slide after slide explaining talent, process, and commitment to excellence. Everyone insists they are fast, strategic, and powered by artificial intelligence. It all blends together. 

And just as in basketball, none of it matters until you see the dunk. 

Why Enterprise AI Partner Evaluation Has Changed 

I have spent the last year watching something shift in how enterprise buyers evaluate technology partners. The change is not subtle. AI collapsed the timeline for what is possible. Engineers use artificial intelligence to automate repetitive tasks, reveal gaps, and support rapid iteration. User experience teams model real behavior and refine interactions in a fraction of the usual time. Designers explore and adapt visual directions quickly while matching a client’s brand and needs. At the strategy level, artificial intelligence helps teams explore concepts, identify edge cases, and clarify problems before anyone designs anything or writes code. 

Teams can now build first versions far earlier than they once could. It is now possible to walk into a meeting with something real, rather than something hypothetical. 

Traditional Evaluation Arrives Too Late  

Yet enterprise evaluation still moves as if early builds take months. Teams can create quickly, but organizations are asked to decide slowly. Forrester’s 2024 Buyers’ Journey Survey reveals the scale of this shift: 92% of B2B buyers now start with at least one vendor in mind, and 41% have already selected their preferred vendor before formal evaluation even begins. Traditional vendor selection leans on slides that outline intent, case studies that point backward, and demos that highlight features. These keep judgment at arm’s length and often arrive too late to matter. 

An early milestone changes that dynamic. A deck explains. A first version proves. 

What Functional Products Reveal About AI Vendors 

A healthcare technology company came to us through a partner referral. They needed to modernize their pharmacy network’s web presence, which included hundreds of independent pharmacy websites, each with unique branding and content, all needing migration into a modern, SEO-optimized content management system. They had already sat through multiple vendor presentations that week. Each promised speed, AI capabilities, and transformation. 

At Robots & Pencils, we stopped presenting what we could do and started showing what we already built. 

Building the Functional Product in 10 Days 

Our team had a week and a half. Our engineers used AI agents to automate content scraping and migration. Our UX team modeled user flows and tested assumptions in days instead of weeks. Our designers explored visual directions that preserved each pharmacy’s brand identity while modernizing the experience. Our strategy team identified edge cases and clarified requirements before a single line of production code was written. 

We walked into the meeting with a functional product. 

The Client Demo: Testing Real Data in Real Time 

The client entered one of their pharmacy’s existing URLs into our interface. They selected brand colors. They watched our AI agents scrape content, preserve branding structure, and generate a modern, mobile-responsive website in real time. Within minutes, they were clicking through an actual functioning site built on a production-grade CMS with an administrative backend. This was not a mockup or a demo, but a working system processing their real data. 

The entire conversation shifted. They immediately started testing edge cases. What about mobile responsiveness? We showed them the mobile view that we had already built based on pre-meeting feedback. What about the administrative interface? We walked them through the CMS backend where content could be updated. They stopped asking, “Can you do this?” and started asking “What else can we build together?” and “How quickly can we expand this?” 

After the meeting, their feedback was direct: “I appreciate the way you guys approached us. Going through the demo, it wasn’t just this nebulous idea anymore. It was impressive from a build standpoint and from an administration standpoint.” 

Why Early Functional Products Prevent Partnership Failures 

When clients see a working product, even in its earliest form, they lean forward. They explore. They ask questions. They do not want to return to a deck once they have interacted with actual software. And this is precisely why the approach works. 

Most enterprise partnerships that fail do not fail because of weak engineering or design. They fail because teams hold different pictures of the same future, and those differences stay hidden until it is too late to course correct easily. A shared early version fixes that. Everyone reacts to the same thing. Misalignments surface when stakes are low. You learn how a partner listens, how they adjust, and how you work through ambiguity together. No deck presentation can show these things. 

How Early Functional Delivery Transforms Vendor Selection 

The Baseline Iteration Before Contract Signing 

At Robots & Pencils, we think of this functional product as more than a prototype. It is the baseline iteration delivered before contract signing. It shapes how the partnership forms. The client comes into the work from the start. Their data, ideas, and context shape what gets built. 

Why This Approach Stays Selective 

Because this early delivery takes real effort and investment on our behalf, we keep the process selective. We reserve early functional product development for organizations that show clear intent and strong alignment. The early artifact becomes the first shared step forward, rather than the first sales step. 

The Lasting Impact on Partnership Formation 

When you start by delivering something meaningful, you set the tone for everything that follows. The moment that first version hits the court, the moment you see the lift, the rim, and the finish, the entire relationship changes. 

In the end, the same lesson from basketball holds true. People do not remember the talk. They remember the dunk. And we would rather spend our time building something real than explaining why we could. 

If you want to explore what it looks like to begin with real work instead of a pitch, we would love to continue the conversation. Let’s talk. 

Key Takeaways 

• The evaluation gap is real: AI enables teams to build prototypes in 5-10 days, yet traditional enterprise evaluation still operates on 3-6 month timelines. This mismatch leaves buyers relying on promises instead of proof. 

• Most buyers decide before formal evaluation: 92% of B2B buyers start their journey with at least one vendor in mind, and 41% have already selected their preferred vendor before formal evaluation begins. Early proof matters more than polished presentations. 

• Partnership failures stem from misalignment, not capability: Enterprise AI implementations rarely fail due to weak engineering or design. They fail because teams hold different pictures of the same future, differences that stay hidden until it’s too late to course correct easily. 

• Functional products reveal what presentations cannot: A shared early version shows how a partner interprets requirements, handles real constraints, navigates tradeoffs, and collaborates under pressure. No deck can demonstrate these partnership dynamics. 

• Early functional delivery changes the conversation: When prospects interact with a working product built with their actual data, the conversation shifts from “Can you do this?” to “What else can we build together?” Trust forms through shared work, not sales process.

FAQs

How long does early functional delivery take to create? 

Early functional product delivery typically takes 5-10 days, depending on complexity and data availability. At Robots & Pencils, we focus on demonstrating how we interpret requirements, handle real constraints, and collaborate under actual conditions rather than achieving feature completeness. 

What makes this approach different from a proof of concept? 

Unlike traditional proofs of concept, our baseline iteration is built with the client’s actual data and reflects real-world constraints from day one. It demonstrates partnership dynamics and problem-solving approach, not just technical capability. 

Which types of organizations are best suited for this approach? 

Organizations that show clear intent, strong alignment on objectives, and readiness to engage collaboratively benefit most from early functional delivery. This approach works best when both parties are committed to testing the partnership through real work rather than presentations. 

Can this approach work for regulated industries like healthcare or financial services? 

Yes. We’ve successfully delivered early functional products for healthcare technology companies and financial services organizations. The approach adapts to industry-specific requirements while maintaining rapid delivery timelines. 

The post Product, not PowerPoint: How to Evaluate Enterprise AI Partners  appeared first on Robots & Pencils.