Skip to content

AIYINGFrom AI Awareness to Accomplishment

Showing posts with label POwer AI. Show all posts

Showing posts with label POwer AI. Show all posts

Wednesday, November 4, 2026

POrable #009: The Engineer Who Planned to Be Forgotten

PORABLES — FROM DEADLOCK TO POSSIBILITY

POrable #009: The Engineer Who Planned to Be Forgotten

By Ravindra Dastikop

The story

Every morning, Kavya explained the project again.

The AI coding agent had worked on it the previous afternoon. But after a fresh session began, it sometimes repeated completed work, overlooked an earlier decision or announced that an unfinished feature was ready.

Kavya wrote longer instructions.

Soon, the instructions needed instructions.

She worked on the agent’s harness: the software and working arrangements that supplied context, connected tools and organised its execution.

Her colleague suggested keeping the conversation going for longer.

Kavya looked at the growing history.

“What if the agent forgot me completely—and still knew exactly where to begin?”

She wrote the thought down.

Perhaps the project could introduce itself. Perhaps every stopping point could become an arrival point. Perhaps the next session could discover the state of the work without hearing the whole story.

She chose the second possibility.

Before improving the next instruction, she redesigned the handover.

The project received a short starting page linking to its requirements, decisions and current work. Each feature had an observable acceptance condition.

At the end of a work session, the agent was asked to record what changed, which checks had actually run, what remained uncertain and the next useful step. Changes were saved in version control.

The following morning, Kavya deliberately opened a fresh session.

“Continue the project.”

The agent read the starting page and inspected the latest changes.

The handover said the booking form was complete.

The acceptance check disagreed.

A booking appeared on screen, but disappeared after the page was refreshed.

Previously, Kavya might have discovered that during a demonstration.

This time, the restart routine required the agent to verify the existing application before adding another feature.

It reproduced the failure and resumed work on the booking form.

Later, another session encountered conflicting notes. It paused and asked Kavya which decision remained valid.

She corrected the record.

The handover system wasn’t infallible. It had made the uncertainty visible.

Over the next week, Kavya compared the revised harness with the earlier setup on the same tasks, using separate clean workspaces and repeated runs.

She tracked completed acceptance checks, repeated work, recovery effort, time and cost.

Some tasks benefited. Others showed little improvement. Maintaining the records also took effort.

She kept the parts that helped and simplified the rest.

At the next team meeting, someone asked whether she had finally made the agent remember everything.

“No,” Kavya said.

“I made it easier to find out what’s true.”

↑ Back to contents

The PO behind the story

“PO: The agent forgets me completely—and still knows where to begin.”

The provocation shifted Kavya’s attention from preserving every conversation to making the project’s current state discoverable and verifiable.

↑ Back to contents

Spot the lock

Kavya assumed that continuity depended on carrying more conversation forward.

What essential knowledge exists only in your chat history—or in your own memory?

↑ Back to contents

Find the gateway

She explored several possibilities before choosing structured handovers.

The practical move was to give a fresh session a reliable starting point, supported by evidence of the work already done.

The record guided the agent. Checks could challenge the record.

↑ Back to contents

Try the move

Choose a small project and prepare a handover containing:

The intended outcome and acceptance conditions.
The current version of the work.
Decisions and unresolved questions.
Checks performed and their results.
The next useful step.

Start a fresh session and observe where it struggles. Compare its account with the actual project state.

Treat the handover as a working record that needs verification and maintenance.

↑ Back to contents

Research note

This fictional POrable draws on published harness-engineering practices. Here, “harness engineer” describes the work Kavya performs; job titles and the boundaries of that work vary.

Persistent project records, structured handovers, incremental work and executable checks are documented approaches. They do not guarantee reliable completion, and their costs and benefits depend on the task, model and implementation.

The characters, dialogue and outcomes are invented. The PO is an original modern adaptation, not a quotation from Edward de Bono.

↑ Back to contents

Further reading

↑ Back to contents

Explore more POrables

POrable #008: The Engineer Who Asked for a Worse Demo

PORABLES — FROM DEADLOCK TO POSSIBILITY

The Engineer Who Asked for a Worse Demo

By Ravindra Dastikop

The story

Every Friday, Dev’s AI demonstration impressed the client.

Every Monday, someone explained why it wouldn’t work in their department.

Dev was a forward-deployed engineer. He worked alongside the client’s staff to turn AI capabilities into a system they could depend on.

But the project had become a procession of successful demonstrations and postponed decisions.

“Make the next demo more convincing,” his manager said.

Dev polished the interface. Improved the examples. Rehearsed the presentation.

Then he stopped.

“What if the next demonstration looked worse—and helped us move forward?”

He opened a blank document.

What could “worse” mean?

More interruptions, perhaps. More unanswered questions. A system that stopped instead of confidently completing everything. A meeting in which customers explained their work while the engineer listened.

One possibility caught his attention.

What if the demonstration’s purpose was to uncover what they still didn’t understand?

At the next meeting, Dev made an unusual request.

“Bring a difficult case that represents your actual work. Use synthetic or appropriately sanitised information. Before we run it, tell me what a useful result would look like.”

The operations lead brought a request with missing information.

“We need the missing details,” she said. “But we shouldn’t have to start the whole request again.”

A specialist brought two documents that contradicted each other.

“Show me the disagreement and where it comes from. Don’t quietly choose one.”

A supervisor brought a case requiring approval from someone outside the room.

“Prepare the recommendation,” he said. “But only the authorised person can approve the action.”

They ran the cases.

The assistant stopped without explaining what information was missing.

It overlooked the contradiction.

Then it proposed an action the user wasn’t authorised to approve.

Dev’s demonstration had never looked worse.

For the first time, the team could put precise requirements beside the failures.

Each case received an expected outcome, an owner and a repeatable check.

Dev began drawing.

Incomplete requests would become requests for specific missing details. Conflicting documents would be surfaced with supporting passages. Restricted actions would become approval requests.

The AI could prepare those requests, but the execution service would act only after verifying the approver’s authority.

“Will this make it ready?” the supervisor asked.

“It gives us something concrete to build and test,” Dev replied.

Over the following days, they tested ordinary requests alongside difficult ones. They repeated trials and reserved additional cases that hadn’t been used while developing the system.

They measured useful completions, missed exceptions, unnecessary escalations and review time. They checked that unauthorised actions remained blocked.

Some changes helped. Others created new problems.

The team revised the workflow and tested again.

When the agreed criteria were met, they began a narrow, monitored pilot.

At the next demonstration, the assistant asked for missing details, highlighted a disagreement and paused for approval.

It looked less effortless.

It looked more like the work the client needed done.

↑ Back to contents

The PO behind the story

“PO: A worse demonstration is progress.”

The provocation did not make failure desirable. It opened a different purpose for the demonstration: discovering requirements rather than displaying effortless success.

The demonstration looked less impressive because it had become more informative.

↑ Back to contents

Spot the lock

Dev assumed that a more convincing demonstration would resolve the client’s hesitation.

What does your demonstration leave out to keep everything running smoothly?

↑ Back to contents

Find the gateway

Dev explored several meanings of “worse” before choosing one to pursue.

The resulting shift was from “Watch what our AI can do” to “Help us discover what this work requires.”

Difficult cases became shared design material. Expected outcomes turned them into evaluation cases.

↑ Back to contents

Try the move

Choose one prototype and invite intended users to contribute three difficult, representative cases using synthetic or appropriately sanitised information.

Before running each case, agree:

What should the system complete?
What should it flag or ask?
Which actions require authority?
How will you check the result?

Test ordinary cases too. Repeat trials and include cases not used during development.

Treat the exercise as a starting point for learning—not proof of deployment readiness.

↑ Back to contents

Research note

This is an original, source-informed fictional POrable. Its depiction of customer collaboration, evaluation and controlled execution draws on published engineering practices.

The characters, dialogue and outcomes are invented. The PO is a modern adaptation, not a quotation from Edward de Bono. The story does not establish that these engineering practices are new or that worse demonstrations inherently produce progress.

↑ Back to contents

Further reading

OpenAI: What FDE means at OpenAI
Anthropic: Demystifying evaluations for AI agents
Microsoft: Authorisation in Microsoft Entra Agent ID
Edward de Bono, Serious Creativity (1992), discussion of stepping-stone provocations, printed pages 168–169.

↑ Back to contents

Explore more POrables

Tuesday, November 3, 2026

POrable #006: The AI Engineer Who Built a Way Out

PORABLES — FROM DEADLOCK TO POSSIBILITY

The AI Engineer Who Built a Way Out

By Ravindra Dastikop

The story

Arjun’s AI assistant worked beautifully in demonstrations.

Real customer requests were another matter.

It sometimes chose the wrong account, misunderstood an instruction or confidently prepared the wrong change.

“We can’t let it act until it stops making mistakes,” his manager said.

Arjun improved the prompts. Added examples. Tried another model.

The mistakes became less frequent. They didn’t disappear.

The release stayed blocked.

One evening, he looked at the deployment checklist and wrote an absurd sentence:

“What if the AI made its mistake after we had already undone it?”

He stared at it.

He couldn’t reverse time. But perhaps he could change where an action became real.

The next morning, he split the assistant’s work into two stages.

First, it proposed a change inside an isolated test workspace. Then a separate process checked the proposal before anything reached the live system.

The AI could prepare a customer-record update, but it had no permission to write to the live database. Only the controlled execution service could apply an approved change.

Arjun added a preview showing exactly which fields would change. Checks verified the customer identifier, permitted fields and required information. Uncertain cases went to a person.

For the narrow set of updates they intended to permit, the system recorded the previous field values and the record’s version. If the record changed after review, the proposal needed checking again.

His manager watched a test.

The assistant selected an account that did not match the verified customer identifier.

The check rejected the proposal. Nothing changed.

In another controlled test, an incorrect update passed the checks and was applied.

Arjun verified that no other changes had occurred, then restored the affected fields from the saved version through a corrective update. He added the failure to their evaluation set.

“So that was a rollback?” his manager asked.

“A correction after the change was committed,” Arjun said. “And it worked under these test conditions. If someone else had changed the record, we’d need to reconcile their work. Restoring an old version blindly could create another mistake.”

“What about sending emails or issuing payments?” his manager asked.

“Those stay outside this release. Restoring a database record can’t unsend a delivered email.”

They continued testing: incorrect requests, conflicting updates, rejected proposals and failed recovery attempts.

Only after repeated evaluations and recovery tests met their agreed acceptance criteria did they launch a monitored pilot for a small set of low-impact, reversible record updates.

Arjun still worked on accuracy. Now he also tracked rejected proposals, missed errors, human interventions and recovery outcomes.

He had spent weeks trying to build an assistant that would never take a wrong turn.

The pilot began when he built boundaries around where it could go—and tested a way back.

↑ Back to contents

The PO behind the story

“PO: The AI’s mistake is undone before it happens.”

The provocation did not become literally true. It led Arjun to prepare controls and recovery before allowing the AI’s proposals to affect live records.

↑ Back to contents

Spot the lock

Arjun had treated eliminating mistakes as the only route to deployment.

Which part of your workflow assumes that an AI output must be correct on its first attempt?

↑ Back to contents

Find the gateway

The provocation shifted his attention from the model’s answer to the system around it: isolated testing, permissions, validation, human review and recovery.

What could change if generating an action and authorising it were separate steps?

↑ Back to contents

Try the move

Choose one low-impact task and use synthetic records in an isolated test environment.

Have the AI propose a change without permission to apply it directly. Inspect the difference, introduce a deliberate error and test whether the execution controls reject it.

Then test recovery from an applied error—including what happens if another legitimate update occurs before recovery.

Use what fails to decide the next improvement.

↑ Back to contents

Engineering note

This fictional story illustrates established practices such as isolated testing, controlled execution and tested recovery. Restoring saved data is not always sufficient: concurrent changes and external effects can make recovery more complex.

PO provides the thinking provocation. It does not guarantee error-free or risk-free operation.

↑ Back to contents

Technical reading

↑ Back to contents

An original fictional POrable applying PO to AI engineering.

Explore more POrables

POrable #005: The Teacher Who Needed a Lesson

PORABLES — FROM DEADLOCK TO POSSIBILITY

The Teacher Who Needed a Lesson

By Ravindra Dastikop

The story

Whenever Ananya asked, “Does everyone understand?” her students nodded.

Their test papers told a different story.

She tried shorter explanations. Better slides. More examples.

The nods continued. So did the mistakes.

One evening, preparing yet another lesson, she stopped.

“What if tomorrow the students taught—and the teacher didn’t understand?”

The next morning, she put a question on the board:

Why does one-half plus one-third not equal two-fifths?

“You’ll explain this to an AI playing a confused beginner,” she said. “Your job is to help it understand. I’ll be listening.”

She had prepared the AI to ask simple questions, request examples and avoid supplying the solution.

A student typed, “You need a common denominator.”

“Why?” the AI asked.

“Because that’s the rule.”

“What does the rule help us do?”

The student paused.

Across the room, another group drew two circles of different sizes. A third group divided a rectangle into six equal pieces.

Ananya walked between the desks, reading and listening.

For the first time, she could see where the nodding had hidden different kinds of uncertainty. Some students remembered the procedure but couldn’t explain it. Others understood equal parts but lost track of them in the calculation.

She put her prepared slides aside.

“Let’s look at what makes two pieces the same size,” she said.

After the discussion, she gave everyone a fresh problem to solve independently—and asked them to explain why their answer made sense.

This time, she had more than nods to work with.

The lesson had begun when the explanations broke down.

↑ Back to contents

The PO behind the story

“PO: The students teach, and the teacher does not understand.”

↑ Back to contents

Spot the lock

Ananya had treated her explanations and the students’ nods as enough reason to move on. Their thinking remained largely invisible until the test.

What do you accept as evidence that someone understands?

↑ Back to contents

Find the gateway

The students’ explanations became the starting point for teaching. The AI’s questions helped expose gaps, and Ananya used those gaps to decide what to teach next.

What could change if the learner’s thinking came before the teacher’s explanation?

↑ Back to contents

Try the move

Choose one topic for your next lesson. Before explaining it, ask learners to explain an example to a partner or an AI playing a beginner.

Listen for one gap. Build a short teaching activity around it. Then use a fresh problem to check whether understanding has improved.

↑ Back to contents

An original fictional POrable applying PO to teaching with AI.

Explore more POrables

Subscribe to: Posts (Atom)