On a Sandy Beach

Industry workspace

Mike's Notes

Working notes, subject to change, on building the first workspaces.

This was initially a proof-of-concept thought experiment with the platform to enable the creation of any future workspace configuration. This is now being rapidly built using modular patterns.

This needs to work for users and their learning, developers and their technical documentation, and be consistent with any schema or industry standards.

These configurations are now being imported into Pipi 9, replacing the settings first created in Pipi 6 and 7.

Contact me if you would like to help with early testing.

After two weeks, the testing results have been a great success, and it was discovered that the UI created is actually a thin wrapper. One of many emergent properties exhibited by Pipi 9, found by volunteer testers.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

13/12/2025

Industry workspace

By: Mike Peters

On a Sandy Beach: 13/10/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Each Ajabbi account type has different SaaS applications.

Issues

Use nouns.
Singular, not plural.
Use standard English industry terms and then translate (i18n).
Organised by Account Type > Applications + Settings.

Account Type

There are 7 role-based account types, each with different workspace properties.

Agent. For Pipi to self-manage.
Developer. For configuring Plugins and building Enterprise or SME workspaces using Pipi objects that can be aliased, recombined, deeply nested, and shared.
Enterprise. For a feature-rich SaaS workspace. Requires an attached Developer account for admin config.
Personal. For everyone with a username, a password, preferences and personal information.
Research. For training Pipi with constraints.
SME. For simple sharded apps with minimal customisation and integration options.
Temp. For temporary anonymised interactions.

Navigation Outline

This is a very rough default outline being used to build the applications, navigation, etc. This changes most days as lessons are learned from user testing.

Agent Account

Applications

Agent

As a Platform (v1)

Cloud Platform

Alibaba Cloud
AWS
Azure
Couchbase
Cloudflare
Container Hosting Service
DigitalOcean
Google Cloud
Hetzner Cloud
IBM Cloud
JFrog
Linode
Netlify
OpenShift
Oracle Cloud
OVHcloud
Render
Salesforce
Tencent Cloud
Vercel
Wasabi
Zeabur

Data Centre (v2)

Cooling
Fire
Power

Live Power
UPS

Security

Mission Control

Status

Customer (v2)

Bookmarks

(To come)

Support

Contact
Forum
Live Chat
Office Hours
Requests
Tickets

(To come)

Feature Vote
Feedback
Surveys

Learning

Explanation
How to Guide
Reference
Tutorial

Settings (v3)

Account
Billing
Deployments

Workspaces

Modules
Plugins
Templates

Mission Control
Researcher
Librarian
Training

Users

Developer Account

Applications

Config (v.3)

Component Class

Design System

Engine

Entity Class

Module

Plugin

AddThis
Amazon Book
Apple Map
Apple Music
ArcGIS Map
Atlassian Analytics
Azure Map
CloudConvert
CodePen
CodeSandbox
Confluence
Elfsight Weather
Flightradar24
FormBlock
GitHub-Embed
GitLab Snippet
Google Analytics
Google Calendar
Google Docs
Google Form
Google Map
Google Meet
Google Sheets
Google Slides
Instagram
IUCN Threat Status
Jira Advanced Roadmap
JSBin
Jupyter Notebook
MailChimp
Metservice Weather
Microsft Forms
NASA Spot the Station
NASA Worldview
NetSuite Case Form
NIWA CO2 Widget
NIWA Tide Widget
NIWA UV Widget
NIWA Weather Widget
Odoo Form
PDF
PostHog Analytics
Survey Monkey
Trello Board
Trello Card
TypeForm
Vimeo Video
Weather Widget
Wolfram Notebook
Yandex Map
Yandex Video
YouTube Video
Zapier
Zoho Calendar
Zoho Form
Zoom Meeting

Tools

Build
Code
Deploy
Document
Feedback
Monitor
Operate
Plan
Release
Test

Customers (v2)

Bookmarks

(To come)

Support

Contact
Forum
Live Chat
Office Hours
Requests
Tickets

(To come)

Feature Vote
Feedback
Surveys

Learning

Explanation
How to Guide
Reference
Tutorial

Settings (v3)

Account
Billing
Deployments

Workspaces

Modules
Plugins
Templates

Solo
Team
DevOps

Users

Enterprise Account

Applications

Agriculture (See separate Workspaces for Agriculture)
Association (v2 was community) (See separate Workspaces for Association)
Built Environment (v.3) (See separate Workspaces for Built Environment)
Civil Defense

(to come)

Culture (v.2) (See separate Workspaces for Culture)

Screen (v3) (See separate Workspaces for Screen)

Health (See separate Workspaces for Health)

Nature Conservation (v.3) (See separate Workspaces for Nature Conservation)

Research (See separate Workspaces for Research)

Transport (v.2) (See separate Workspaces for Transport)

Aviation (v.2) (See separate Workspaces for Aviation)

Website

Blog
Docs
Wiki

Customer (v2)

Bookmarks

(To come)

Support

Contact
Forum
Live Chat
Office Hours
Requests
Tickets

(To come)

Feature Vote
Feedback
Surveys

Learning

Explanation
How to Guide
Reference
Tutorial

Settings (v.3)

Account
Billing
Deployments

Workspaces

Modules
Plugins
Templates

Farm
--------
Art Class
Art Studio
Concert Hall
FX Studio
Set Workshop
Theatre
--------
(To come)
--------
Earthquake
Flooding
Volcano
--------
Club
Farmers
Union
--------
Civil
Housing
--------
City
Home
Hydroelectric
Nuclear Power Station
Wind Turbine
---------
Church
Mosque
Synagogue
Temple
---------
Plantation
Farm Forestry
---------
Gallery
Library
Archive
Museum
--------
Allied
Animal Vet
Emergency
Family Doctor Clinic
Hospital
Public Health System
Patient
--------
Crop Farm
Plant Nursery
Viticulture
--------
Online
School
---------
Park
Zoo
---------
(To come)
---------
Urban
Model Railway
---------
Institute
Lab
Student
---------
City
---------
Crew
Studio

Preproduction
Production
Post Production
Distribution

Web Cast
----------
City
Home
----------
Depot
----------
City
Home
----------
To come
Captive Breeding
Wildlife Park
Urban Zoo
Marine Aquarium

Users

Personal Account

Applications

Calendar
Health
Profile
Task

Customer (v2)

Bookmarks

(To come)

Support

Contact
Forum
Live Chat
Office Hours
Requests
Tickets

(To come)

Feature Vote
Feedback
Surveys

Learning

Explanation
How to Guide
Reference
Tutorial

Settings (v3)

Account
Deployment (1)

Workspaces

Modules

Research Account

Applications (v.2)

Constraint

Algorithm

Ontology

HMMS
SNOMED

Package

Primative

Space Time

Schema

Standard

Customer (v2)

Bookmarks

(To come)

Support

Contact
Forum
Live Chat
Office Hours
Requests
Tickets

(To come)

Feature Vote
Feedback
Surveys

Learning

Explanation
How to Guide
Reference
Tutorial

Settings (v3)

Account
Billing
Deployments

Workspaces

Modules
Plugins
Templates

Mission Control
Researcher
Librarian
Training

Users

SME Account

Applications

(To come)

Customer (v2)

Bookmarks

(To come)

Support

Contact
Forum
Live Chat
Office Hours
Requests
Tickets

(To come)

Feature Vote
Feedback
Surveys

Learning

Explanation
How to Guide
Reference
Tutorial

Settings (v3)

Account
Billing
Deployment (1)

Workspaces

Modules
Users

Temp Account

Applications

Today

Customer (v2)

(To come)

Feedback
Surveys

Learning

Explanation
How to Guide
Reference
Tutorial

Settings (v3)

Account (0)
Deployment (0)

Workspaces

Modules

Your Users Aren’t Lazy—They’re Managing Change Overload

Mike's Notes

More thoughtful words of wisdom from IT Revolution.

Resources

References

Progressive Delivery: Build The Right Thing For The Right People At The Right Time by James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman (IT Revolution Press, November 2025).

Repository

Home > Ajabbi Research > Library > Subscriptions > IT Revolution
Home > Handbook >

Last Updated

12/10/2025

Your Users Aren’t Lazy—They’re Managing Change Overload

By: Leah Brown

IT Revolution: 02/10/2025

Managing Editor at IT Revolution working on publishing books and guidance papers for the modern business leader. I also oversee the production of the IT Revolution blog, combining the best of responsible, human-centered content with the assistance of AI tools.

Picture this: A seasoned medical coder sits down at her workstation every morning and flies through insurance claims at lightning speed. Her fingers dance across function keys and the ten-key pad without her eyes ever leaving the screen. She processes more claims in an hour than most people could handle in a day.

Then your team delivers a “user-friendly” modernization of her software. Suddenly, she needs a mouse. The keyboard shortcuts she’s memorized over decades no longer work. Tasks that took seconds now require multiple clicks through dropdown menus. Her productivity plummets.

Is she being resistant to change? Lazy? Unwilling to learn?

None of the above. She’s managing change overload in the only way that makes sense: by protecting the workflows that keep her livelihood intact.

This scenario, shared by coauthor Heidi Waterhouse in the upcoming book Progressive Delivery, illustrates a fundamental misunderstanding that’s costing organizations millions in failed software rollouts, user frustration, and abandoned features.

The Change Paradox

Here’s what seems contradictory but is actually perfectly logical: the same person who eagerly upgrades their iPhone every year might resist a minor update to their work software. The same developer who constantly experiments with new programming languages might refuse to adopt your team’s new deployment tool.

This isn’t hypocrisy—it’s smart change management.

People have a finite capacity for absorbing change. We instinctively protect our most critical workflows while remaining open to improvement in areas where failure isn’t catastrophic. Your iPhone upgrade can be undone or worked around. Your work software, which determines whether you can pay your mortgage, demands much more careful consideration.

Beyond Stakeholders: Understanding Your Full Constituency

Most organizations think about their users as “stakeholders”—people who have a financial or organizational interest in the product’s success. But Progressive Delivery requires thinking about “constituents”—everyone who is actually affected by your software, whether they appear on your org chart or not.

Consider medical records software. The obvious stakeholders are:

Doctors who input patient data.
Hospital administrators who purchase the software.
IT teams who maintain the systems.
Your development team who builds features.

But the full constituency includes:

Nurses who need to access information during emergencies.
Patients who use portals to view their own data.
Family members helping elderly relatives navigate health information.
Regulatory bodies ensuring privacy compliance.
Insurance companies processing claims.
Medical billers like our friend above.

Each constituent has different change tolerance levels, different technical sophistication, and different stakes in maintaining stability versus embracing innovation.

The Three Types of Change Capacity

Not all users approach change the same way. Understanding these differences is crucial for delivering software that actually gets adopted:

The Builder Mindset Some users see software as LEGO blocks—they want to understand how things work and customize their experience. These are your early adopters who read release notes, experiment with beta features, and provide detailed feedback. They have high change tolerance because they enjoy the process of discovery and optimization. They’re willing to invest time learning new workflows because they see it as creative problem-solving.
The Tool Mindset Most users see software as a hammer—they want it to reliably perform specific tasks without requiring constant attention. They’ve developed efficient workflows around current functionality and view changes through the lens of “will this help me get my job done better?” They have moderate change tolerance when improvements clearly align with their goals, but they resist changes that disrupt established patterns without obvious benefit.
The Survival Mindset Some users interact with software in high-stakes environments where mistakes have serious consequences. Medical professionals, financial traders, air traffic controllers—these users have optimized their workflows for safety and reliability above all else. They have very low change tolerance because their primary concern isn’t efficiency improvement—it’s avoiding catastrophic failure.

The Cost of Misreading Your Constituency

When you misunderstand your users’ change capacity, you create what Progressive Delivery calls “technological jerk“—the jarring experience of change happening too fast for people to absorb.

Slack’s 2019 redesign perfectly illustrates this mismatch. Slack’s design team saw an opportunity to create a more modern, streamlined interface. They were thinking like builders—excited about cleaner visual hierarchy and improved information architecture. But most Slack users weren’t builders—they were people managing dozens of conversations across multiple workspaces while trying to get their actual jobs done. The redesign disrupted muscle memory, changed keyboard shortcuts, and reorganized familiar layouts. What felt like an improvement to the design team felt like chaos to users trying to maintain productivity.

Sonos’s 2024 app disaster represents an even more dramatic failure. The company released an app update that broke core functionality like sleep timers and queue management. Users weren’t just annoyed—they were unable to perform basic tasks with expensive hardware they’d already purchased. CEO Patrick Spence was forced to resign in January 2025.

In both cases, the companies built better software from a technical perspective but failed to consider how changes would land with people who depended on existing workflows.

The Adobe Alternative: Progressive Control

Adobe provides a masterclass in respecting user change capacity while still driving innovation. When they integrated AI into their Creative Cloud suite, they could have simply pushed the latest models to everyone simultaneously. Instead, they implemented what Progressive Delivery calls “radical delegation.”

Users can choose which AI model version to use for different projects. Someone working on a long-term brand campaign can maintain consistency with Firefly v1, while someone experimenting with new creative techniques can opt into Firefly v3. The same user might make different choices for different contexts.

This isn’t just about offering a “classic mode” checkbox. Adobe created granular controls that let users manage their own change absorption rate based on their specific needs and risk tolerance.

Three Strategies for Respecting Change Capacity

Delegate Control to the Point of Impact: Instead of deciding when users should adopt new features, give them the tools to make that decision themselves. Microsoft’s “Try the new Outlook” toggle lets users test the redesigned experience and revert if needed. Google Workspace offers separate release tracks for organizations with different change tolerance levels. The key is making this choice meaningful—not just a temporary beta flag that eventually disappears, but ongoing control over their experience.
Design for Multiple Speeds Simultaneously: Your power users and cautious users don’t need to move at the same pace. GitHub ships hundreds of small changes that are mostly invisible to casual users but provide meaningful improvements for developers who spend all day in the platform. Meanwhile, major feature releases are carefully communicated and gradually rolled out. This allows your constituency to self-select into the change pace that matches their capacity and context.
Build Reversible Experiences: Make it safe to experiment by making it easy to step back. This isn’t just about technical rollback capabilities—it’s about user confidence. When people trust they can explore new functionality without getting trapped in unfamiliar territory, they’re more willing to try changes. Netflix’s interface experiments are a good example. They test thousands of variations, but users never feel stuck with a version they dislike because the changes are either subtle or easily reversible.

The Empathy Advantage

Organizations that successfully implement Progressive Delivery share a crucial insight: user “resistance” is usually valuable information about change capacity, not character flaws to overcome.

When users complain about the pace of updates, they’re telling you about their bandwidth for absorption. When they create workarounds to avoid new features, they’re showing you that your timing doesn’t match their readiness. When they stick with “legacy” workflows, they’re protecting something valuable that you might not understand.

Instead of viewing this feedback as obstacles to overcome, Progressive Delivery treats it as essential input for delivering software that actually creates value.

The Path to Sustainable Innovation

Here’s the paradox: When you respect users’ change capacity, you can actually innovate faster. Users who trust that you won’t disrupt their critical workflows are more willing to experiment with new capabilities. Users who feel heard and respected become advocates rather than resistors.

Progressive Delivery isn’t about slowing down innovation—it’s about ensuring innovation actually reaches the people who need it, when they’re ready to receive it.

Your users aren’t lazy. They’re not change-averse. They’re not technologically backward.

They’re intelligent people managing complex workflows in environments where stability matters. They’re making rational decisions about where to invest their limited change capacity. They’re protecting their ability to be productive while remaining open to genuine improvements.

The question isn’t how to overcome user resistance. The question is how to build delivery systems that work with human change capacity rather than against it.

When you get that right, everyone wins: users get software that actually makes their lives better, and you get the sustainable adoption that drives real business value.

This post explores concepts from the upcoming book Progressive Delivery: Build The Right Thing For The Right People At The Right Time by James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman (IT Revolution Press, November 2025).

The most powerful medicine we have

Mike's Notes

Doing the rounds at the moment.

Resources

https://www.uams.edu

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

11/10/2025

The most powerful medicine we have

By: A US Physician

UAMS Patient Experiences group: 01/10/2025

Note by Kristen Koll

From a US physician [And in response to those who have asked: I am still trying to confirm authorship, but the post appears to originate from UAMS Patient Experiences group (facebook page) and I’ve messaged them to see if the author can be named. Also, they confirmed in response to another query that the names are pseudonyms, so HIPAA privacy was not violated]

I know the exact pressure it takes to crack a rib during CPR. But last Tuesday, I learned a patient’s silence can break a doctor’s soul.

His name was David Chen, but on my screen, he was "Male, 82, Congestive Heart Failure, Room 402." I spent seven minutes with him that morning. Seven minutes to check his vitals, listen to the fluid in his lungs, adjust his diuretics, and type 24 required data points into his Electronic Health Record. He tried to tell me something, gesturing toward a faded photo on his nightstand. I nodded, said "we'll talk later," and moved on. There was no billing code for "talk later."

Mr. Chen died that afternoon. As a nurse quietly cleared his belongings, she handed me the photo. It was him as a young man, beaming, his arm around a woman, standing before a small grocery store with "CHEN'S MARKET" painted on the window.

The realization hit me like a physical blow. I knew his ejection fraction and his creatinine levels. I knew his insurance provider and his allergy to penicillin. But I didn't know his wife's name or that he had built a life from nothing with his own two hands. I hadn’t treated David Chen. I had managed the decline of a failing organ system. And in the sterile efficiency of it all, I had lost a piece of myself.

The next day, I bought a small, black Moleskine notebook. It felt like an act of rebellion.

My first patient was Eleanor Gable, a frail woman lost in a sea of white bedsheets, diagnosed with pneumonia. I did my exam, updated her chart, and just as I was about to leave, I paused. I turned back from the door.

"Mrs. Gable," I said, my voice feeling strange. "Tell me one thing about yourself that’s not in this file."

Her tired eyes widened in surprise. A faint smile touched her lips. "I was a second-grade teacher," she whispered. "The best sound in the world... is the silence that comes just after a child finally reads a sentence on their own."

I wrote it down in my notebook. Eleanor Gable: Taught children how to read.

I kept doing it. My little black book began to fill with ghosts of lives lived.

Frank Miller: Drove a yellow cab in New York for 40 years.

Maria Flores: Her mole recipe won the state fair in Texas, three years running.

Sam Jones: Proposed to his wife on the Kiss Cam at a Dodgers game.

Something began to change. The burnout, that heavy, gray cloak I’d been wearing for years, started to feel a little lighter. Before entering a room, I’d glance at my notebook. I wasn’t walking in to see the "acute pancreatitis in 207." I was walking in to see Frank, who probably had a million stories about the city. My patients felt it too. They'd sit up a little straighter. A light would flicker back in their eyes. They felt seen.

The real test came with Leo. He was 22, angry, and refusing dialysis for a condition he’d brought on himself. He was a "difficult patient," a label that in hospital-speak means "we've given up." The team was frustrated.

I walked into his room and sat down, leaving my tablet outside. We sat in silence for a full minute. I didn't look at his monitors. I looked at the intricate drawings covering his arms.

"Who's your artist?" I asked.

He scoffed. "Did 'em myself."

"They're good," I said. "This one... it looks like a blueprint."

For the first time, his gaze lost its hard edge. "Wanted to be an architect," he muttered, "before... all this."

We talked for twenty minutes about buildings, about lines, about creating something permanent. We didn't mention his kidneys once. When I stood up to leave, he said, so quietly I almost missed it, "Okay. We can try the dialysis tomorrow."

Later that night, I opened my Moleskine. I wrote: Leo Vance: Designs cities on paper.

The system I work in is designed to document disease with thousands of data points. It logs every cough, every pill, every lab value. It tells the story of how a body breaks down.

My little black book tells a different story. It tells the story of why a life mattered.

We are taught to practice medicine with data, but we heal with humanity. And in a world drowning in information, a single sentence that says, "I see you," isn't just a kind gesture.

It’s the most powerful medicine we have.

Pipi release cadence

Mike's Notes

The current work on building SaaS workspaces has raised the question of the Pipi release cadence. Documentation also has to be versioned. Then there is the monthly research newsletter. Here is a plan to use Fridays to create a rhythm of deadlines.

I was deeply influenced by writings from Shopify and Refactoring.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library > Subscriptions > Refactoring
Home > Handbook > Teams > Cadence

Last Updated

2/01/2026

Pipi release cadence

By: Mike Peters

On a Sandy Beach: 10/10/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

There have been thousands of changes to Pipi since version 9, but the official Pipi version is frozen till full automated self-management kicks in 2026. This is a description of what will happen then.

Pipi Versioning

Pipi uses Semantic Versioning <major>.<minor>.<patch>+<build>

Example

9.04.23+1453455072

Build

Every change to a namespaced object increments the Build Number by 1
It is the internal system change ID
Daily Builds could vary from 0 to 1,000s
Never resets.

Patch

Release daily if there have been Build Number increases
Numbered 0-999
Resets when a Minor Release occurs
Minor documentation edits

Minor Release

Release 4x per year, 3 months apart on the 2nd Friday.
Numbered 0-99
Resets when a Major Release occurs
Documentation officially updated

Major Release

Release when a Minor Release backwards-incompatible change occurs, on the 2nd Friday of January, April, July or October.
Usually every 2-3 years
Numbered 1-99
New documentation released
Account migration required

On a Sandy Beach

Published daily
My notes on building Pipi, a self-organising platform to support critical infrastructure

Friday Report

Published every Friday
A summary of the week's work is sent to other researchers.

Research Newsletter

Published 12x per year on the 1st Friday.
Numbered 1-99999
Dated by month and year, eg "January 2026"
Named by theme, eg " Design Systems Issue"

Cadence

Type	What	Date
Newsletter	Workspace	1st Friday, January
Release	9.1.0	2nd Friday, January
Newsletter	Accessibility	1st Friday, February
Newsletter		1st Friday, March
Newsletter		1st Friday, April
Release	9.2.0	2nd Friday, April
Newsletter	Origins of Pipi	1st Friday, May
Newsletter		1st Friday, June
Newsletter	i18n	1st Friday, July
Release	9.3.0	2nd Friday, July
Newsletter		1st Friday, August
Newsletter	Open Handbook	1st Friday, September
Newsletter		1st Friday, October
Release	9.4.0	2nd Friday, October
Newsletter	Complex Adaptive Systems	1st Friday, November
Newsletter		1st Friday, December

Agentic Design Patterns

Mike's Notes

This book looks interesting.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

09/10/2025

Agentic Design Patterns

By: Antonio Gulli

On a Sandy Beach: 01/10/2025

Note by Pawel Huryn

The Product Compass

A senior AI engineer at Google just dropped a 400-page book for review: Agentic Design Patterns.

It’s got everything about AI agents + code:

Prompting
MCP
Tools
RAG
Memory
Humans in the loop
Multi-agent
Guardrails
You name it

You can read it here (Google Drive + links to chapters): docs.google.com/documen…

Remember to pre-order (published by Springer): a.co/d/b5SxY8t (all royalties go to Save the Children).

Agentic Design Patterns

A Hands-On Guide to Building Intelligent Systems Antonio Gulli

Table of Contents - total 424 pages = 1+2+1+1+4+9+103+61+34+114+74+5+4 11

Dedication, 1 page

Acknowledgment, 2 pages [final, last read done]

Foreword, 1 page [final, last read done]

A Thought Leader's Perspective: Power and Responsibility [final, last read done]

Introduction, 4 pages [final, last read done]

What makes an AI system an "agent"?, 9 pages [final, last read done]

Part One, (Total: 103 pages)

Chapter 1: Prompt Chaining (code), 12 pages [final, last read done, code ok]
Chapter 2: Routing (code), 13 pages [fina, last read done, code ok]
Chapter 3: Parallelization (code), 15 pages [final, last read done, code okl]
Chapter 4: Reflection (code), 13 pages [final, last read done, code okl]
Chapter 5: Tool Use (code), 20 pages [final, last read done, code ok]
Chapter 6: Planning (code), 13 pages [final, last read done, code ok]
Chapter 7: Multi-Agent (code), 17 pages [final, last read done, code ok], 121

Part Two (Total: 61 pages)

Chapter 8: Memory Management (code), 21 pages [final, last read done, code ok]
Chapter 9: Learning and Adaptation (code), 12 pages [final, last read done, code ok]
Chapter 10: Model Context Protocol (MCP) (code), 16 pages [final, last read done, code ok]
Chapter 11: Goal Setting and Monitoring (code), 12 pages [final, last read don, code oe], 182

Part Three (Total: 34 pages)

Chapter 12: Exception Handling and Recovery (code), 8 pages [final, last read done, code ok]
Chapter 13: Human-in-the-Loop (code), 9 pages [final, last read done, code ok]
Chapter 14: Knowledge Retrieval (RAG) (code), 17 pages [final, last read done, code ok], 216

Part Four (Total: 114 pages)

Chapter 15: Inter-Agent Communication (A2A) (code), 15 pages [final, last read done, code ok]
Chapter 16: Resource-Aware Optimization (code), 15 pages [final, last read done, code ok]
Chapter 17: Reasoning Techniques (code), 24 pages [final, last read done, code ok]
Chapter 18: Guardrails/Safety Patterns (code), 19 pages [final, last read done, code ok]
Chapter 19: Evaluation and Monitoring (code), 18 pages [final, last read done, code ok]
Chapter 20: Prioritization (code), 10 pages [final, last read done, code ok ]
Chapter 21: Exploration and Discovery (code), 13 pages [final, last read done, code ok],330

Appendix (Total: 74 pages)

Appendix A: Advanced Prompting Techniques, 28 pages [final, last read done, code ok]
Appendix B - AI Agentic ….: From GUI to Real world environment, 6 pages [final, last read done, code ok]
Appendix C - Quick overview of Agentic Frameworks, 8 pages [final, last read done, code ok] ,
Appendix D - Building an Agent with AgentSpace (on-line only), 6 pages [final, last read done, code ok]
Appendix E - AI Agents on the CLI (online) , 5 pages [final, last read done, code ok]
Appendix F - Under the Hood: An Inside Look at the Agents’ Reasoning Engines, 14 pages [final, lrd, code ok],
Appendix G - Coding agents, 7 pages 406

Conclusion, 5 pages [final, last read done]

Glossary, 4 pages [final, last read done]

Index of Terms, 11 pages (Generated by Gemini. Reasoning step included as an agentic example) [final, lrd]

Online Contribution - Frequently Asked Questions: Agentic Design Patterns

Pre Print:>https://www.amazon.com/Agentic-Design-Patterns-Hands-Intelligent/dp/3032014018/

[1] All my royalties will be donated to Save the Children

8 load balancing algorithms you should know

Mike's Notes

I found this via Neo Kim's SubStack. Very useful.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

11/01/2026

8 load balancing algorithms you should know

By: Petar Ivanov

The T-shaped Dev: 05/09/2025

A weekly newsletter sharing practical tips on React, Node, and Software Architecture. Elevate your Full-Stack JavaScript skills to the next level!.

1. Round Robin:

It sends each new request to the next server in a rotating order.
Useful when all servers have similar capabilities and you want to spread the load evenly.

2. Least Connections:

It directs traffic to the server with the fewest active connections.
Useful when servers have different workloads, balancing them more efficiently.

3. Weighted Round Robin:

It gives more requests to servers with higher weights or capacities.
Useful when some servers are more powerful and can handle more traffic.

4. Weighted Least Connections:

It considers both server capacity and current connections to assign requests.
Useful when servers differ in performance, ensuring a fair distribution.

5. IP Hash:

It uses the client's IP address to decide which server will handle the request.
Useful to keep a client connected to the same server, which is important for session consistency.

6. Least Response Time:

It sends requests to the server with the quickest response and fewest connections.
Useful to reduce delays and improve the user experience.

7. Random:

It picks a server at random for each new request.
Useful when you don't need to consider server load or differences in server capacity.

8. Least Bandwidth:

It directs traffic to the server using the least network bandwidth at the moment.
Useful when managing network usage is important to prevent congestion.

[IMG]

Image Credits: DesignGurus

How SQL JOINs work

Mike's Notes

Another gem from Neo Kim. I'm a visual learner and like the use of Venn Diagrams in the sketch.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library > Subscriptions > The System Design Newsletter
Home > Handbook >

Last Updated

07/10/2025

How SQL JOINs work

By: Neo Kim

The System Design Newsletter: 01/10/2025

(explained in 2 mins or less):

Inner join
It returns rows with matching values in both tables
Full outer join
It returns all rows when there is a match in either the left or the right table
Full outer exclusive
It returns all rows from both tables with no match in the other table
Left join
It returns all rows from the left table and matched rows from the right table
Left exclusive
It returns rows from the left table with no match in the right table
Right join
It returns all rows from the right table and matched rows from the left table
Right exclusive
It returns rows from the right table with no match in the left table
Cross join
It returns the Cartesian product of both tables; every combination of rows
Self join
It joins a table with itself to compare rows within the same table

The JOIN clause lets you combine data from tables based on a related column.

What else?

Workspace URL naming pattern decision

Mike's Notes

I was able to decide on the workspace URL naming pattern after conducting some experiments over the last week.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

25/10/2025

Workspace URL naming pattern decision

By: Mike Peters

On a Sandy Beach: 06/10/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Over the last week, I have been experimenting with different URL naming patterns. I had to devise patterns for Pipi to use when it automatically generates SaaS applications with User Interfaces (UI).

Note: The URLs below don't link to anything.

Learning from others

I looked at how common and very popular cloud products use URL naming patterns, including;

Google Workspace
MuleSoft
Odoo
Salesforce
ServiceNow
Zoho

Conclusion

I started with the simplicity of Google and ended with the richness of ServiceNow. The pattern simply needs to be predictable and consistently effective. The URLs after the i18n codename need to be in the local language, eg French.

Components

The Pipi-generated URLs will be made up of the following parts;

User account, eg demo
Device/screen specific, eg mobile m , braille b , kiosk k , VR v
Platform, eg cloud.ajabbi.com
i18n code, eg eng-UK
Major version, eg 9
Account type, eg e for enterprise
Account subtype, eg a for app, s for settings
Industry name, eg rail
One or more nested industry objects, eg rolling stock
CRUD verbs, eg patient-new
Multi instances directory, eg email/e/
ID etc can be masked as a UUID, eg durmdis7d3kbp
Workflow specific, eg page/administer/ui-builder/concept

Pattern examples

demo.cloud.ajabbi.com/eng/9/e/a/screen/location/l/adytenm.html
demo.m.cloud.ajabbi.com/fra/9/e/a/écran/emplacement/e/adytenm.html

URL masking and pattern configuration

It should be straightforward for a User Account holder to mask these URLs and modify other pattern configurations.

m.rail.example.com/en-au/rolling-stock/rolling-stock-new/
m.en-au.example.com/rail/rolling-stock/new/
en-au.bigrail.com/rolling-stock/r/2945/history/
k.en-au.app.bigrail.com/rolling-stock/r/2945/history/

Industry names

Third draft revision of the Pipi 6 industry names used for English i18n URLs. This has been imported into Pipi 9 for testing purposes. The nouns are singular.

Agriculture: agriculture/
Art: art/
Aviation: aviation/
Conservation: conservation/
Construction: construction/
Drainage: drainage/
Electricity Supply: electricity-supply/
Forestry: forestry/
GLAM (Galleries-Libraries-Archives-Museums): glam/
Health: health/
Horticulture: horticulture/
Learning: learning/
Port: port/
Rail: rail/
Research: research/
Road: road/
Screen (was Film): screen/
Sewer: sewer/
Transport: transport/
Water Supply: water-supply/
Website: website/
Zoo: zoo/

Next steps

Begin creating full-page mockups for community testing.
Adjust as necessary

Using free tiers on the cloud

Mike's Notes

A job starting in the next few months. I'm gathering information for now.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

12/10/2025

Using free tiers on the cloud

By: Mike Peters

On a Sandy Beach: 05/10/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I need to learn how to work with multiple cloud platforms. Many offer a generous free tier for learning and production. Initially, I thought I would do all the available training and just build things.

Then move part of the Ajabbi/Pipi infrastructure to all of these platforms, staying within the free-tier limits.

This means being able to use MSSQL, Postgres, Oracle, MySQL, etc. And being familiar and confident with multiple languages like .NET, PHP, Java, Python, Go, etc

VMs, Kubernetes, Docker, et al.

This is preparation for when paying customers decide to use Pipi as part of their enterprise SaaS, on their platform of choice. At least I will be ready.

Known available free tiers (more to come)

Alibaba Cloud
AWS
Azure
Cloudflare
Container Hosting Service
DigitalOcean
Google Cloud
Hetzner Cloud
IBM Cloud
JFrog
Linode
Netlify
OpenShift
Oracle Cloud
OVHcloud
Render
Salesforce
Tencent Cloud
Vercel
Wasabi
Zeabur

Pages

Mike's Notes

Resources

References

Repository

Last Updated

Industry workspace

Issues

Account Type

Navigation Outline

Mike's Notes

Resources

References

Repository

Last Updated

Your Users Aren’t Lazy—They’re Managing Change Overload

The Change Paradox

Beyond Stakeholders: Understanding Your Full Constituency

The Three Types of Change Capacity

The Cost of Misreading Your Constituency

The Adobe Alternative: Progressive Control

Three Strategies for Respecting Change Capacity

The Empathy Advantage

The Path to Sustainable Innovation

Mike's Notes

Resources

References

Repository

Last Updated

The most powerful medicine we have

Mike's Notes

Resources

References

Repository

Last Updated

Pipi release cadence

Pipi Versioning

Build

Patch

Minor Release

Major Release

On a Sandy Beach

Friday Report

Research Newsletter

Cadence

Mike's Notes

Resources

References

Repository

Last Updated

Agentic Design Patterns

Agentic Design Patterns

Part One, (Total: 103 pages)

Part Two (Total: 61 pages)

Part Three (Total: 34 pages)

Part Four (Total: 114 pages)

Appendix (Total: 74 pages)

Mike's Notes

Resources

References

Repository

Last Updated

8 load balancing algorithms you should know

1. Round Robin:

2. Least Connections:

3. Weighted Round Robin:

4. Weighted Least Connections:

5. IP Hash:

6. Least Response Time:

7. Random:

8. Least Bandwidth:

Mike's Notes

Resources

References

Repository

Last Updated

How SQL JOINs work

Mike's Notes

Resources

References