Next.js Blog Theme

sprantic


You sell building automation products — controllers, sensors, actuators. But the real growth is in digital services: energy monitoring, predictive maintenance, indoor climate optimization. Every new customer needs onboarding. Every service needs commissioning. And every handoff between sales, engineering, and operations is where weeks disappear.

## The Problem Nobody Models

Service activation that should take 3 days takes 3 weeks. Not because people are slow, but because the process between people is invisible. It lives in email chains, tribal knowledge, and spreadsheets last updated two product generations ago. Your best commissioning engineer is your biggest single point of failure — and when they go on vacation, everything stops.

Meanwhile, auditors ask "show me when this building was commissioned and who signed off." You scramble through shared drives and somebody's phone photos. This is not an audit trail. This is forensic archaeology.

## Camunda as Process GPS

Camunda doesn't replace your engineers. It gives them a GPS for the service delivery process. You draw the onboarding process visually as a flowchart. The engine runs it step by step. Humans handle site-specific judgment calls. Systems handle cloud provisioning and notifications. Everyone sees which buildings are live and which are stuck.

The results speak for themselves: average commissioning time down from 18 to 7 days. Service activation SLA compliance up from 68% to 93%. And that data is a byproduct — you just turn on the dashboard.

## The Data Question

The instinct is to wire up every system before starting. Don't. Your first onboarding workflow needs three connections: CRM for the customer, IoT platform for provisioning, and email for notifications. The hybrid pattern is simple: read from data products (building profiles, equipment catalogs), write to source systems (IoT platform, billing), orchestrate with Camunda.

## Making It Real

The first 6 weeks will feel slower — that's the J-curve. You'll discover that sales, engineering, and operations each have a different version of "the onboarding process." This feels like failure. It's actually the most valuable phase. Teams that push through get real-time dashboards. Teams that quit go back to shared inboxes.

The full story is told as an immersive visual experience. Explore the [interactive version](/workflows-that-work) with all 16 chapters, background imagery, and the complete set of best practices for bringing process orchestration to smart building services.


How process orchestration with Camunda transforms digital service delivery in smart buildings. An immersive visual guide covering the chaos, the solution, the data question, and the transformation.

Workflows That Work — Camunda in Smart Buildings

/images/workflows/post-01-invisible-factory.jpeg


For decades, the bottleneck in software delivery was building the thing. You had the idea, you had the specification - however vague - and you fed it into a machine made of developers, sprints, and standups. The machine was slow and expensive, so the organisation built a whole bureaucracy to manage it. Portfolio layers, program increments, PI planning ceremonies that consume entire weeks. Architecture review boards. Agile coaches coaching other agile coaches. All of it, at its root, was load-bearing scaffolding for a slow build process.

AI-assisted development is pulling that scaffolding away. Not gradually. Quickly.

When a competent developer with the right tooling can produce in a day what used to take a sprint, the entire governance apparatus built around slow delivery starts to look absurd. The cost model breaks. The timeline assumptions collapse. And suddenly the constraint is not where anyone expected to find it.

## The pressure is reversing direction

This is the dynamic that most organisations are not prepared for, and it is already happening in pockets everywhere. Development used to be the long tail - the part where ideas went to get slowly, painfully realised. Management's job was to funnel requirements in and wait for output. That direction of flow made sense when building was the hard part.

Now building is becoming cheap. Fast. Almost mechanical when the inputs are good. And here is the thing about AI coding assistants that nobody in portfolio management wants to hear: they are absolutely ruthless about bad inputs. You hand an AI a vague epic with half-formed acceptance criteria and it will cheerfully generate something that looks like software, compiles without complaint, and solves the wrong problem entirely. It fills the gaps you left with its best guess. Its best guess is often spectacular nonsense.

So developers - freed up from the grinding execution work, finally able to lift their heads and think about what they are actually building - start asking questions. Sharp questions. Questions about data consistency rules that nobody has written down. About edge cases in asynchronous business processes that have never been modelled. About what actually happens when two events arrive out of sequence. These are not unreasonable questions. They are the questions any serious engineer should be able to ask. The difference is that now they have the time and the cognitive space to ask them.

The questions land on the desks of Product Managers, Business Analysts, Scrum Masters, Portfolio Managers. And most of these people are not equipped to answer them. Not because they are not smart - many of them are very smart - but because the skill set that got them into those roles was a different skill set. Managing stakeholders. Facilitating alignment. Writing epics that are ambitious enough to get approved and vague enough not to be wrong. Being wrong at the requirement level used to be invisible. It only showed up as delivery problems, and delivery problems were the development team's fault.

That comfortable arrangement is over.

## The requirement is now load-bearing in a new way

When the build cycle compresses from months to weeks, the cost of a bad requirement is not absorbed across a long delivery timeline. It hits immediately. You get working software for the wrong thing, fast. And then you have to explain that to someone.

This is where the concept I want to introduce becomes necessary: **Epic as Code**.

I mean this literally, not metaphorically. The development of early requirement artefacts needs the same alertness, the same precision, and the same willingness to crash and revise that we expect in executable software. The epic is not a narrative artefact. It is a specification. And specifications should be treated with the discipline of code.

Code has properties that PowerPoint does not. It is unambiguous in a way that language cannot be. It forces you to define your data structures, which forces you to understand your domain. It fails loudly when the logic does not hold. If you have not thought through the consistency rules, the code will not run. There is no "we will figure this out in a later sprint" moment. The gaps show up immediately.

Early vibe coding attempts - just prompting an AI with a rough idea and seeing what comes out - failed for exactly this reason. The AI generates confidently and completely into whatever shape you gave it, including all the unexplored corners. The result looks finished and is hollow. The same failure mode applies to the front end of the lifecycle when requirements are treated as narrative artifacts to be discussed rather than structures to be validated.

An epic that is developed with code-level rigour does not have to be a real application. It does not need to be production-ready. It needs to be a working expression of the core idea, applied into the real environment, checked against actual constraints, and built up as a strategic backbone for what comes next. It is a probe. And like any good probe, its second most important function is failing when the idea does not hold. Kill it early if it does not fit. That is not failure. That is the system working correctly.

## Who does this work?

Not the current product management population, at least not without significant retooling. The people who can do this - who can bridge the strategic intent and the technical expression, who can pick up tooling without getting lost in it, who understand both the organizational constraints and the data model - these are Enterprise Architects and the more technically grounded Analysts. Scarce resources. But exactly positioned for this moment.

These people need access to what I would call the AI twins of the enterprise silos: the actual code repositories, the wikis, the knowledge stores, the architecture models - whatever form the organisational memory takes, however imperfect. Nobody should need to call a meeting to understand how data flows between two systems. If the meeting is still necessary, that is a symptom of an information architecture problem that has been deferred for years, probably decades. AI tooling can help pull it out of the Confluence graves and SharePoint archives into something usable, but someone has to do that work before the requirement shaping starts.

The truly advanced organisations will have a knowledge graph, a capabilities model, a RAG store that makes this information queryable. Most will not be there. Most will be working with the digital mess they accumulated through twenty years of tool proliferation and undocumented decisions. That is fine. You start where you are. But you have to start.

What changes is the output of this early phase. Instead of workshop outputs and whiteboard photos and strategy decks, you have working artefacts. Runnable probes. Demonstrated assumptions. Code that either fits into the environment or breaks against it. When the conversation about whether to continue shifts from opinions to findings, the quality of that conversation changes fundamentally. The politics do not disappear, but they become harder to sustain against a working proof of concept.

Once a project moves into proper delivery, these early artefacts become the most valuable input the team receives. Not because they are complete specifications, but because the hard questions have already been asked, the key assumptions have been tested, and the shape of the problem is clear. The AI-assisted delivery cycle can then run fast and clean, which is what it was designed to do.

The organisations that figure this out first will not get there by hiring more Scrum Masters. They will get there by taking the requirement discipline seriously - by treating the front end of the lifecycle with the same rigour they finally learned to apply to delivery. Epic as Code is not a tool recommendation or a process framework. It is a reorientation of where the hard work happens.

It happens earlier than you think. It starts now.


When building becomes cheap and fast, the requirement becomes load-bearing in a new way

Epic as Code: Why AI Is Finally Forcing the Requirements Problem Into the Open

/images/2026-02-19-epic-as-code.png


When I first started using Claude Code, it felt like a powerful but somewhat opaque tool. You type a prompt, it writes code, and magic happens. But as I dug deeper, I realized there's an entire architecture of extension points underneath — a composable system of 12 distinct mechanisms that, once understood, transforms how you work with AI-assisted development. I decided to map it all out visually because I couldn't find a single reference that showed the complete picture.

## Why This Matters

The shift from "AI as chatbot" to "AI as development platform" is one of the most significant changes happening right now. Claude Code isn't just answering questions — it's running in a lifecycle with hooks, permissions, memory, tools, and agents that you can customize at every level. Understanding this architecture is like understanding the extension model of your IDE: once you see the seams, you start building on top of them rather than just using the surface.

What struck me most while mapping this out is how thoughtfully the layers compose. You can start with nothing more than a CLAUDE.md file — a simple markdown document with instructions — and progressively add sophistication. Skills give Claude domain expertise. Hooks automate lifecycle events deterministically, outside the AI entirely. MCP servers connect to external APIs via an open protocol. Custom agents let you define specialized personas with their own tools and permissions. And plugins bundle all of this into distributable packages.

## The Session as the Central Concept

Everything revolves around the session lifecycle. From the moment a session starts — loading instructions, connecting MCP servers, reading memory — through each prompt-inference-tool cycle, to the final transcript save at session end, every extension mechanism has a well-defined place where it plugs in.

The architecture diagram traces this flow step by step, showing which mechanisms activate at each stage. The PreToolUse hook, for example, is the only point where external code can actually *block* an action (by returning exit code 2). That's a deliberate design choice: security gates belong at specific, auditable points in the lifecycle, not scattered throughout.

## Memory That Compounds

One aspect I find particularly elegant is the memory system. Auto-memory gives Claude per-project persistent knowledge via MEMORY.md files — the first 200 lines load automatically at every session start, with topic-specific files loaded on demand. Combined with session transcripts saved as JSONL and automatic context compaction when conversations grow long, you get an AI that genuinely learns about your project over time.

This isn't just a convenience feature. It fundamentally changes the economics of working with AI. Instead of re-explaining your project's architecture, coding conventions, and quirks in every session, Claude accumulates understanding. The context window isn't just a technical limit anymore — it's a managed resource with explicit strategies for what persists, what summarizes, and what reloads.

## Agents and the Future of Delegation

The agents layer is where things get truly interesting for enterprise development. Subagents spawn isolated contexts for parallel or specialized work. Custom agents defined in markdown files get their own tools, models, and permission modes — an analyst agent doesn't need write access, a reviewer agent can run in plan mode. And the experimental agent teams feature hints at a future where multiple Claude instances coordinate through shared task lists and peer-to-peer messaging, with no central manager required.

This is the kind of architecture that scales. Not just technically, but organizationally. Teams can define project-level agents, share MCP configurations, enforce coding standards through managed policies, and still allow individual developers their personal customizations.

## A Composable Philosophy

The architecture follows a clear three-pillar philosophy: **Define** what Claude knows and can access, **Automate** what should happen deterministically at lifecycle boundaries, and **Extend** capabilities through external tools and delegation. Each pillar has multiple mechanisms, but they all share a common design language — markdown for instructions, JSON for configuration, lifecycle events for integration points.

What I appreciate most is the restraint. Every mechanism has a clear purpose and doesn't try to do everything. CLAUDE.md is for always-on instructions; skills are for triggered domain expertise; hooks are for deterministic automation. The boundaries are clean, which means the system stays comprehensible even as it grows more powerful.

The full architecture reference is available as the title image above. There's also an [interactive version](/claude-code-architecture) with expandable details for each mechanism if you want to explore the specifics.


A visual guide to every customization mechanism in Claude Code and how they connect — 12 mechanisms forming one composable system.

Claude Code — Extension Architecture

/images/claude-code-architecture-preview.png


The AI world in 2025 looks a lot like waves at the beach that come in so fast they stumble over themselves. One innovation barely hits shore before another crashes right on top of it.

Remember when ChatGPT first dropped? Before companies could even figure out how to use it, GPT-4 arrived. Then came better image generators, Claude models, and now we've got AI systems that handle text, images, and audio all at once. Each wave pushes forward before the last one has even broken.

This is exactly like wave steepening in physics. As waves approach shore, they compress and rise until they become unstable and collapse. AI hype cycles are doing the same thing—compressing into shorter and shorter timeframes.

Companies are exhausted trying to keep up, investing in systems that become outdated almost immediately. VCs pour money into the space in frenzied cycles. Media coverage swings wildly between utopian dreams and dystopian nightmares. And regulators? They're completely underwater, drafting rules for yesterday's AI while tomorrow's makes those concerns obsolete.

Unlike ocean waves that eventually dissipate, these AI waves seem to be building on each other, creating something bigger with each crash. The people and organizations who can surf this chaos—staying balanced while everything breaks around them—will be the ones who thrive.
For now, grab your metaphorical surfboard. The next AI wave is already forming, and it's coming in fast.

I for my part will go now and do some Model Context Protocol deep-diving - yet another wave rolling in 😅

The AI world in 2025 looks a lot like waves at the beach that come in so fast they stumble over themselves.

Riding the AI Hype Wave Crash

/images/waves.webp


I love patterns! They represent concentrated problem-solving and understanding. Their sleek and elegant display instantly sparks engagement. It's 60 years now that Christopher Alexander published his groundbreaking book "Notes on the Synthesis of Form" that explores the design process, viewing design as the creation of new physical order and form in response to function. The book discusses diagrams as key elements, which Alexander has referred to as patterns in his later work, when he started systematically to collect them to build up a systematic method for designing products, buildings, or settlements.

I find that playing with patterns significantly contributes to my thought process, helping me integrate new information and connect disparate areas of expertise. Beyond their practical applications, I appreciate patterns simply for their beautiful presence and the way they enhance my understanding.

## unFIX

In the image, you'll see two of my favorite pattern collections which are perpetually present on my desk. First, the unFIX organization design patterns, presented as card sets. I created these from templates available for free within the unFIX community. These cards are invaluable for me in navigating challenging situations, offering a range of choices through their tangible and manageable format. The unFIX model distinguishes itself by focusing on continuous innovation and prioritizing human experience, offering versatile tools for organizational design. It uses structural patterns to help find the right structure for all value streams.

## Enterprise Design

The second collection is the Enterprise Design Patterns book compiled by members of the Intersection Group. 35 patterns are thoughtfully categorized into four key impact areas: Impact, Behavioural, Practice, and Creations. They provide confirmation, reassurance, and inspiration when I need to apply them in real-world scenarios. Navigating the complex and evolving structures of organizations can be daunting, and these patterns offer a welcome helping hand. The Enterprise Design Patterns offer practical solutions applicable to enterprise design, helping to improve identity, experience, and architecture. And, you see the Designer's handwriting 😉

## EDGY

From that book it is a small jump to another product of the [Intersection Group](https://intersection.group/). They created [EDGY](https://enterprise.design/) to help people work together to design better organizations. It's a simple, colorful visual language that anyone can learn quickly, regardless of their background. When designers, architects, and business folks try to improve an organization, they often speak different languages and miss each other's insights. EDGY bridges these gaps by giving everyone a shared way to visualize and discuss how enterprises work. 

Their latest release, "EDGY 23," lays the foundation with basic concepts that connect different perspectives. They've made it visually appealing and straightforward while still powerful enough to handle complex organizational challenges. Whether you're a UX designer, business analyst, or decision-maker, EDGY gives you tools to collaborate more effectively and create the enterprises we want to see in the world. 

The EDGY approach complements my existing pattern collections nicely. For me, it's a versatile beautiful tool offering another perspective on how patterns can be systematically applied to create meaningful change in organizational contexts. Try it out, it's free!

Focusing on problematic spaces and proven solutions.

On Patterns in Enterprise Design

/images/patterns.webp


I have always been fascinated by the way systems connect—the way data flows, the way processes interact, and the way organizations evolve. My work has focused on efficiency: optimizing workflows, streamlining automation, and ensuring that every task in a pipeline is executed in the correct sequence. In parallel to business processes, data transformation graphs became essential for me over time. Directed Acyclic Graphs (DAGs) provide a reliable structure, ensuring orderly execution. They are like recipes: clear steps, precise dependencies, and minimal ambiguity.

## The Role of DAGs in Process and Data Management

DAGs power my understanding of data transformations, helpful not only for data consolidation but also for workflow orchestration, and task scheduling. They are reliable, structured, and deterministic. However, I began to notice their limitations when it came to representing deeper relationships. DAGs tell us what happens next, but they do not capture why things connect or how they influence each other. They are excellent for execution but do not inherently convey meaning.

## Introducing Knowledge Graphs as an Enrichment

This is where knowledge graphs come in—not as a replacement for DAGs, but as an enrichment. Unlike DAGs, which focus on execution order, knowledge graphs embed meaning into structure. They introduce context, inference, and domain understanding. They don’t just tell us that something happens; they help us understand why it matters and how different elements relate beyond sequential steps.

## The Relationship Between DAGs and Knowledge Graphs

DAGs and knowledge graphs serve different yet complementary purposes. DAGs are primarily execution-driven—they define a flow of tasks, ensuring that processes unfold in a structured sequence. Knowledge graphs, on the other hand, define relationships and meaning, enabling reasoning beyond simple execution paths.

## Can We Map DAGs to Knowledge Graphs?

While both DAGs and knowledge graphs describe relationships, their fundamental purposes differ significantly. DAGs are designed to capture ordered execution and dependencies, while knowledge graphs aim to represent conceptual and semantic relationships. This makes direct conversion non-trivial.

* From DAG to Knowledge Graph: While it is possible to extract knowledge from a DAG, much of the inherent semantics in a knowledge graph is absent from a DAG. A DAG describes execution order, but it lacks rich contextual meaning. Simply enriching DAG edges with labels such as "depends on" or "transforms into" does not necessarily make it a true knowledge graph. Instead, a deeper semantic modeling effort is required to add domain knowledge, entity types, and reasoning layers.

* From Knowledge Graph to DAG: A subset of a knowledge graph can sometimes be structured as a DAG for execution purposes, but this is a reductive transformation. The hierarchical, ordered structure of a DAG strips away the richer, bidirectional relationships and inference capabilities of a knowledge graph. In cases where process automation is needed, extracting specific paths from a knowledge graph to structure them as a DAG can be useful, but it does not fully leverage the graph’s inferential power.

Rather than focusing on direct conversion, a more effective approach is to use DAGs and knowledge graphs together: DAGs ensure structured execution, while knowledge graphs provide contextual enrichment and adaptability. This hybrid approach allows organizations to design workflows that are not just structured but also adaptive, providing both execution efficiency and contextual awareness.

## Can AI Bridge the Gap?

Given the complexity of mapping execution-driven structures like DAGs to meaning-based structures like knowledge graphs, AI offers a potential bridge. AI-driven techniques, such as:

* Ontology Learning: AI can analyze DAG-based workflows and infer possible ontologies by identifying recurring patterns and relationships, enriching DAG structures with domain knowledge.

* Graph Embeddings: Machine learning can help derive latent relationships within data, offering ways to transform execution paths into semantically meaningful entities and edges.

* Automated Knowledge Extraction: Natural language processing (NLP) and AI-powered reasoning systems can extract implicit knowledge from structured DAG processes, inferring connections that go beyond simple execution dependencies.

While AI can assist in bridging the gap, the fundamental difference remains—DAGs are execution-focused, whereas knowledge graphs are meaning-focused. AI can enhance and automate certain aspects of the transition, but human-guided modeling remains essential for ensuring that the added semantics align with real-world needs.

## Complementing DAGs with Knowledge Graphs

Recognizing this, I started to see how knowledge graphs could complement DAGs. Rather than replacing execution-focused workflows, knowledge graphs provided additional depth. I began to think beyond just defining steps and started defining ontologies—formal models that described relationships, influences, and dependencies. Edges in a KG were not just transitions; they carried semantic meaning, transforming simple workflow dependencies into structured knowledge.

## A Broader Perspective: Networks of Influence

This shift in perspective extended beyond data processing. In organizations, hierarchies are often seen as rigid structures, but they can also be viewed as networks of influence and knowledge exchange. In process management, true efficiency isn’t just about execution speed but about understanding the deeper relationships that shape outcomes. Even biological systems follow a similar principle—life isn’t merely a sequence of steps but an intricate web of interactions.

## The Balance Between DAGs and Knowledge Graphs

DAGs remain essential for execution, automation, and process orchestration. They provide structure and order where needed. However, knowledge graphs complement this by adding reasoning and adaptability. Together, they form a more comprehensive framework: DAGs ensure execution, while knowledge graphs enhance understanding, enabling more intelligent and adaptable systems. The key is not choosing one over the other but leveraging both where they add the most value.

Direct Acyclic Graphs and their relation to Knowledge Graphs

From Graph to Graph - Understanding Data Connectivity

/images/2025-02-25-from-graph-to-graph.png


Technology has made sending information effortless—too effortless. A single click, an automated workflow, and messages flood inboxes. The result? Overwhelmed recipients, fragmented attention, and a widening gap between what is sent and what truly matters.

The core issue is imbalance. Sending is cheap. Receiving is expensive.

Once, communication required effort—paper, postage, time. That effort was a filter, ensuring only necessary messages were sent. Today, that filter is gone. AI has amplified the problem, accelerating communication without consideration. Attention is now the scarcest resource, buried under an avalanche of low-value messages.

We need a new contract between sender and receiver. A shift from frictionless transmission to meaningful exchange.

## Intent Over Volume  
Not every message needs to be sent. The real question isn't can I send this? but should I send this? AI should act as a gatekeeper, filtering noise before it reaches recipients, ensuring only relevant, high-value communication makes it through. 

## AI-Assisted Prioritization  
Inbox overload isn't just an inconvenience—it's a productivity killer. AI should work for the recipient, not just automate the sender's workload. Smart messages, not more messages. AI must sort, summarize, and highlight, reducing cognitive load instead of adding to it.

## Effort-Based Sending  
When sending is effortless, overcommunication is inevitable. Introducing cost—through sender verification, reputation tracking, or prioritization quotas—ensures that messages are worth the recipient's attention. If it matters, it's worth effort.

## Asynchronous by Default  
Real-time communication should not be the default. AI can structure updates into logical flows instead of constant interruptions. Less noise, more signal.

## Subscription Models for Information  
Recipients should choose how much information they receive and when. Instead of a flood of data, let them opt-in to daily summaries, real-time alerts, or periodic reports. AI can scale this personalization seamlessly.

## Feedback Loops  
Unread emails and ignored reports aren't just a nuisance—they signal a broken system. AI should help senders adjust—shorter messages, clearer structures, better timing. Over time, the system should learn, adapt, and optimize.

This isn't about less communication. It's about better communication. AI made sending easy—now it must make receiving manageable.


Technology has made sending information effortless — too effortless

AI in Companies - We Need a New Contract Between Sender and Receiver

/images/2025-02-21-ai-in-companies-we-need-a-new-contract.png


Let me tell you a story. Imagine you’re running a decentralized organization inspired by Betacodex principles. Your teams (or "cells") are autonomous, self-organized, and laser-focused on delivering value. But as your organization grows, so does complexity. Processes start to overlap, communication slows down, and suddenly, your once-agile cells feel more like a tangled web. 
This is where Kafka, Camunda, and the right process design patterns come into play. Let’s dive into two process diagrams and explore how they can help you regain clarity, speed, and flow. 

## The Two Diagrams: A Tale of Simplicity vs. Complexity 

![Diagram 1: The Basic Flow](/images/2025-02-19-from-chaos-to-flow-diagram1-light.png "Diagram 1: The Basic Flow")  

This diagram is like a straightforward to-do list. Tasks are connected in a clear sequence, with decision points (XOR gateways) guiding the flow. Each swimlane in this process represents a team or role. 

But here’s the catch: 

* Communication between tasks is implicit.

* It assumes everyone knows what to do next without needing to talk.

* It works great for simple, linear processes, but what happens when things get more complex?

![Diagram 2: Communication-Enhanced Flow](/images/2025-02-19-from-chaos-to-flow-diagram2-light.png "Diagram 2: Communication-Enhanced Flow")
 
Now, imagine you’ve added Kafka to the mix. This diagram explicitly models message flows (those cute envelope icons 📩). Tasks don’t just pass the baton—they send events through Kafka topics, ensuring everyone gets the memo. 

Here’s why this matters: 

* Communication is explicit, making it easier to track who’s talking to whom.

* It’s perfect for event-driven architectures, where tasks trigger each other asynchronously.

* It aligns beautifully with Camunda, which can orchestrate workflows while Kafka handles the streaming.

💡 Did you notice the left side of the swim lane here? It is also split in three parts - this means we have in reality three autonomous processes instead of one! 

## Kafka + Camunda: The Dynamic Duo 

Think of Kafka as the nervous system of your organization. It connects all the cells, ensuring they can exchange information in real time. Meanwhile, Camunda acts as the brain, orchestrating workflows and making sure everything happens in the right order. 

Here’s how they work together: 

1. A task in Camunda triggers an event and publishes it to a Kafka topic. 

2. Another task (or even another cell) listens to that topic and starts its process. 

3. Kafka ensures that events are decoupled, meaning tasks don’t need to know about each other directly. 

In real life, think of Camunda tasks as complex sub flows, and Kafka topics as Streaming Data Products which can act as the go-to-place for specific data needs. 

## Cell Design: Why This Matters 

In a Betacodex-inspired organization, cells are designed to be autonomous. But autonomy doesn’t mean isolation—it means interdependence without bottlenecks. 

* Diagram 1 works for independent cells with minimal communication needs. For example, a team that handles a self-contained process.

* Diagram 2 is essential for interconnected cells. When one cell finishes its task, it sends an event through Kafka, triggering another cell to act. This ensures smooth collaboration without micromanagement.

## A Real-World Example 

Let’s say you’re running an e-commerce platform. Here’s how the diagrams play out: 

Diagram 1: Basic Flow 

* A customer places an order.

* The order is processed, and the warehouse is notified.

* The warehouse ships the product.

This works fine for a small operation, but what if you need to scale? 

Diagram 2: Communication-Enhanced Flow with Kafka 

* The customer places an order. Camunda triggers an event to Kafka (e.g., OrderPlaced).

* The warehouse listens to the OrderPlaced topic and starts preparing the shipment.

* Meanwhile, the billing system listens to the same topic and processes the payment.

* If the warehouse finishes first, it sends an OrderShipped event, which triggers a notification to the customer.

Now, tasks are happening in parallel, and your system is both scalable and resilient. And, you just added asynchonicity which means you can model your flows in a way that they react to unplanned intermediate events - this is where basic flows most often fail in real life! 

## Key Takeaways 

🌟Diagram 1 is great for simplicity but struggles with complexity. 

🌟Diagram 2 shines in dynamic, event-driven environments where communication is key. 

🌟Pairing Kafka with Camunda creates a powerful system for managing workflows in a decentralized, scalable way. 

🌟In a cell-based organization, explicit communication ensures autonomy doesn’t lead to chaos. 

## What’s Your Flow? 

As your organization grows, so does the need for better process design. Whether you’re building workflows for autonomous teams, orchestrating tasks with Camunda, or scaling with Kafka, the right diagram can make all the difference. 
What challenges are you facing in your processes?



Imagine you are running a decentralized organization inspired by Betacodex principles. Now you need to scale...

From Chaos to Flow - How Kafka, Camunda, and Cell Design Work Together

/images/2025-02-19-from-chaos-to-flow.png


The way we structure knowledge is changing. Traditional hierarchies, slow-moving repositories, and top-down knowledge management systems are being replaced by something more fluid—**cellular intelligence**. A network of independent, knowledge-driven units that adapt, learn, and optimize in real-time. This isn’t just an evolution—it’s a necessary response to complexity.

## What Defines a Corporate Cell’s Value?

At its core, every cell is a **transformation unit**—taking in inputs and producing meaningful outputs. But knowledge is the real catalyst. A cell’s success depends on how effectively it cultivates, maintains, and applies its intelligence to shifting challenges. The real question is: **How does a cell quantify its success?**

## The Core Mechanics of a Cell

The **atoms** of a cell are its members—primarily human today, but increasingly AI-driven. Knowledge doesn’t emerge in isolation. It begins with individuals, scales through collaboration, and solidifies through structured learning. The stronger the internal connectivity, the greater the adaptability.

## The Evolution of Knowledge

The 1990s brought us **Knowledge Management**, treating knowledge as an asset to be stored and retrieved like inventory. Then came **Harold Jarche’s** Seek, Sense, Share framework, shifting the focus to individuals curating and making sense of their own learning journeys. By 2015, **John Stepper’s** Working Out Loud turned knowledge-sharing into a dynamic, social process—an organic system of discovery rather than a rigid repository.

## The Shift to Continuous Learning

Self-directed and social learning aren’t perks. They are the **operating system** of modern knowledge work. The real value isn’t just in preserving knowledge but in enabling it to **flow**—bridging human expertise with machine intelligence in a constant feedback loop. 

## The Cell’s DNA: The Knowledge Graph

A **knowledge graph** is the digital DNA of a cell—mapping relationships, expertise, and capabilities. It serves both human workers and AI, making intelligence visible, discoverable, and actionable. This isn’t just about storing knowledge—it’s about making it **move**.

## How Cells Interact & Succeed

Cells don’t operate in isolation. **Discovery services** allow them to match their expertise with demand using graph-based algorithms. Success metrics emerge naturally—not imposed from the outside but shaped by historical patterns, contextual relevance, and adaptive positioning.

## The Future: A System That Learns

Blending **Personal Knowledge Management with dynamic cellular intelligence** creates a responsive, self-improving system. This isn’t just about organizing knowledge better—it’s about building organizations that **think, learn, and evolve** in real-time. The future belongs to those who master this flow.


The way we structure knowledge is changing. Traditional hierarchies, slow-moving repositories, and top-down knowledge management systems are being replaced.

Cellular Intelligence - Reimagining the Future of Organizational Knowledge

/images/2025-02-17-cellular-intelligence.png


Cell structure design is changing the way we think about organizations. It moves away from rigid hierarchies and embraces autonomy. Meanwhile, enterprise process orchestration has long been about control—ensuring alignment, efficiency, and execution at scale. So, do these two models clash? Or do they, in fact, complement each other?

## The Tension Between Control and Autonomy

At first glance, process orchestration and cell structure design look like opposites. Cells thrive on independence. They own their workflows, make their own decisions, and move fast. Traditional orchestration, on the other hand, wants everything standardized, every dependency mapped out, every process under control. If done poorly, orchestration suffocates autonomy.

But what if orchestration wasn’t about control? What if, instead, it was about *enablement*?

## How Orchestration Can Support Cell Autonomy

#### Event-Driven Over Command-Driven

Instead of hardcoded workflows, orchestration should act as an event-based coordination system. It lets cells decide what signals to act on without forcing predefined steps.

👉 A finance cell can adjust credit approvals based on real-time risk signals without waiting for centralized approval.

#### Decentralized Decision-Making 

With Global VisibilityCells should operate independently but still have access to shared insights. Orchestration can provide visibility without interference.

👉 A manufacturing cell tweaks production based on demand signals from other units, without waiting for HQ to intervene.

#### Flexible Standardization

Orchestration should offer best-practice templates, not rigid instructions. Cells need the freedom to modify and adapt based on their local context.

👉 A customer service team in one region can adjust workflows while staying within an overarching model.

#### AI-Guided Optimization, Not Micromanagement

AI can monitor performance across cells, suggest improvements, and highlight inefficiencies—without mandating control.

👉 An AI system detects inefficiencies in different cells and offers suggestions, instead of enforcing strict process control.

## The Best Approach: Hybrid Orchestration

The solution isn’t centralization vs. autonomy. It’s a hybrid approach:

🌟 Lightweight, API-driven orchestration—cells interact but aren’t constrained by rigid dependencies.

🌟 Event-driven interactions—triggered only when necessary, without excessive coordination.

🌟 AI-driven insights—helping cells self-optimize without top-down mandates.

🌟 Community-driven learning—where teams refine their models, manage signals, and optimize processes collectively.

If process orchestration is built for autonomy rather than control, it becomes a catalyst—not a constraint. The real question isn’t whether orchestration and cell structures are in conflict. It’s whether we’re willing to rethink orchestration itself.



Cell structure design is changing the way we think about organizations. It moves away from rigid hierarchies and embraces autonomy.

Process Orchestration & Cell Structure Design - Conflict or Complement?

/images/2025-02-13-enterprise-process-orchestration-cell-structure-design.png


I’ve noticed that my personal “context window” feels like it’s constantly stretching to accommodate new AI breakthroughs 🤖, emerging research, and cross-disciplinary insights. While that expansion is exciting, it also puts pressure on my mental and physical well-being. Feeling like I have to “know it all” can be overwhelming.

#### Here’s how I’m finding balance

🔍 **Selective Curiosity**  
I used to chase every interesting project or paper. Now, I focus on areas that genuinely spark my interest. It keeps my context window manageable and helps me go deeper in topics that truly resonate.

🧘 **Mindfulness & Reflection**  
Journaling, meditation, and even short mental breaks throughout the day have helped me stay grounded. They keep me from feeling like my mind is running on overdrive, which ultimately benefits my overall health.

🤝 **Community & Collaboration**  
Connecting with peers across different fields reassures me that I’m not alone in struggling to keep up with everything. We share resources, offload some research tasks to each other, and preserve our mental bandwidth.

⚙️ **Leveraging AI Tools**  
Ironically, embracing AI to summarize research and automate tasks frees up cognitive space for creative problem-solving—rather than feeling overwhelmed, I let AI handle some of the heavy lifting.

🚙 **And of course, being on the road with my Campervan 😊**  

If you’ve felt weighed down by your ever-expanding “context window,” know that you’re not alone. Small changes in focus, intentional self-care, and strategic use of technology can make all the difference. Let’s keep exploring the frontiers of knowledge—without sacrificing our well-being!


I have noticed that my personal context window feels like it’s constantly stretching to accommodate new AI breakthroughs

Managing an Expanding Context Window

/images/2025-02-08-managing-my-context-window.png


After working for quite some time in a mesh of deep complexities, I always find it refreshing to discover tools that simplify efforts without compromising effectiveness. One such gem I’m currently testing is [ShadowTraffic](https://shadowtraffic.io/).

A simple yet powerful tool for generating realistic streaming data—without the usual headaches.

## Key Features:

✅ **Declarative Data Generation** – Define data structures that align with your business needs, and let ShadowTraffic handle the rest.

✅ **Multiple Backends** – Supports Kafka, S3, Postgres, and more, making it incredibly flexible.

✅ **Containerized & Lightweight** – Easy to deploy, integrates smoothly into existing workflows.

Currently, I’m using it to simulate production traffic into Kafka and validate data flows efficiently. The ease of setup and the structured approach to data generation make it a great addition to any data engineering toolkit.

Do you have a favorite tool for simulating streaming data?


How to support your end-to-end tests in streaming data environments

Streamlining Data Simulation with ShadowTraffic

/images/2025-02-07-streamlining-data-simulation-with-shadowtraffic.png


We keep getting this wrong. The world of organizations is still obsessed with hierarchy, with legacy structures designed for control rather than value. The truth is, we already know how to do better. It just requires a shift — a subtle but profound one.

## The “Cell” Paradigm

A first outcome of our exploration is the notion of “Cells,” our unique term for self-contained micro-services and micro-frontends. Each Cell handles a specific set of functionalities — whether they’re backend services or user-facing UI components — while remaining independently deployable and scalable. Our broader environment further connects these Cells via a Data Mesh (for shared data accessibility and governance) foundation to our Enterprise Process Orchestration (for seamless workflow coordination across services).

## Why Cells? (And What About Token Limits?)

One of the key reasons for dividing applications into smaller Cells is the token limit challenge often encountered with large language models. When working with AI for code generation, feeding a massive, monolithic codebase into a model quickly exceeds that model’s capacity to process and respond effectively. By breaking down functionality into smaller, more focused Cells, each codebase remains small enough to fit within prompt engineering constraints. This ensures that Generative AI can review, generate, and refine code more accurately without running into token-related issues.

This modular approach also offers practical advantages:

✅ Faster Iterations: Updates or changes in one Cell can be tested and deployed independently.

✅ Reduced Complexity: Smaller codebases simplify maintenance and foster clear boundaries.

✅ Scalability & Focus: Teams can specialize in a single Cell’s domain, driving deeper expertise.

## Cells Need an Operational Approach

While Cells provide a technical foundation, they require an operational framework to fully unlock their potential. Without structured guidance, decentralized units can drift apart, losing coherence and efficiency. This is where Cell Structure Design (CSD) comes in — a socio-technical approach rooted in BetaCodex principles. It provides a way to coordinate autonomous Cells without resorting to rigid top-down structures.

CSD enables Cells to function effectively by embedding decision-making within teams while maintaining alignment across the broader system. It emphasizes self-organization, decentralized leadership, and a focus on value rather than hierarchy. Rather than relying on large-scale transformation programs, CSD encourages gradual, organic change — shifting power to where work actually happens.

## How does Cell Structure Design work?

Think of it as a way to organize work that actually makes sense. Instead of rigid departments, endless approval chains, and transformation programs that take years, Cell Structure Design is about self-organizing units — Cells — that optimize for value, not bureaucracy. It’s decentralized by design. Leadership happens inside the teams, not outside them. Instead of waiting for permission, change happens in the daily decisions made by people who actually do the work.

The philosophy? “Change is like adding milk to coffee.” Small shifts accumulate. Real transformation isn’t a program — it’s a practice.

## Too Radical? Too Idealistic?

Not really. This isn’t some futuristic utopia; it’s already happening. The future, as William Gibson put it, is just unevenly distributed. Bayer is one of the latest examples. In 2024, their CEO, Bill Anderson, announced a radical transformation. Within a year, they converted a key production site — quietly, effectively, and without a massive consulting army. A fully operational decentralized structure, implemented in the real world, inside a global company. If a multinational giant can do this, what’s stopping everyone else?

## Why This Fits With Data Mesh

If this sounds familiar, it’s because the same shift is happening in data. Data Mesh, another socio-technical approach, realized that centralized control creates bottlenecks. Instead of one monolithic system, Data Mesh treats data like a product, owned and managed by decentralized teams. The lesson is the same: complexity doesn’t scale, but autonomy does.

## A Glimpse of New Roles (But Not the Whole Story)

While we’re still evaluating how best to structure teams in an AI-driven model, we’ve identified a duo that can accelerate development cycles:

✅ Generative Cell Engineer: Combines development, architecture, and AI expertise to generate code snippets, refine them, and maintain best practices for a Cell.

✅ Cell Value Manager: Focuses on the Cell’s business requirements, shaping its vision and ensuring that stakeholder needs are met.

By pairing a Generative Cell Engineer with a Cell Value Manager, we will shorten communication loops, eliminate unnecessary handoffs, and make decisions more quickly. This setup aims to deliver new features or improvements at a near-daily pace — recognizing the well-known maxim that simply “throwing more developers” at a project is rarely an effective way to accelerate timelines.

In larger solutions, traditional Solution Engineers and Product Managers would guide the overall architecture and roadmap across dozens or even hundreds of Cells.

## The Connection Between AI, Data, and Cell Structure Design

AI and automation make this shift even more relevant. Traditional organizations rely on layers of management to process information and make decisions. But AI changes this. With the ability to analyze vast amounts of data instantly, decision-making can move closer to the frontlines. Teams equipped with the right data can act faster and more effectively than a hierarchical system ever could.

Data Mesh aligns perfectly with this concept because it treats data as a decentralized asset, just like Cell Structure Design treats teams. Instead of centralizing everything in a single repository, data is owned and managed by the teams who generate and use it. This ensures better quality, faster insights, and a system that evolves in real-time rather than waiting for top-down directives.

## What’s Next?

The real challenge isn’t in the theory — it’s in convincing organizations to let go of outdated control structures. The companies that embrace these ideas will become more adaptable, more innovative, and ultimately more competitive. The ones that resist? They’ll be left struggling under the weight of their own bureaucracy.

The shift has already begun. The only question is: will you be ahead of it or behind?

How to enable big-scale AI-driven Organizations

Cell Engineering & Cell Structure Design — A Perfect Match

/images/2025-02-03-cell-engineering-and-cell-structure-design.png


## The Rise of AI-Driven Architectures

The emergence of AI-native systems is challenging traditional enterprise models. As companies transition from centralized SaaS solutions to dynamic, on-demand, and composable architectures, a critical question arises: Does this shift signal the decline of SAFe (Scaled Agile Framework)?

The warning signs have been present for some time. SAFe has evolved into an ecosystem of its own, continuously expanding while delivering diminishing returns. Critics, including proponents of Unfix, argue for more adaptable frameworks that align with today’s complexity. Even without AI, SAFe has struggled to keep pace with modern enterprise demands.

## The Issues at Hand

🔹 **From SaaS to AI-Native Workflows**  
AI is replacing monolithic SaaS applications with autonomous AI agents, dynamic workflows, and serverless infrastructure. Teams no longer depend on rigid platforms but instead leverage data meshes and automated deployments.

🔹 **SAFe’s Scaling Approach vs. AI-Driven Adaptability**  
SAFe was built around human coordination—structured backlogs, ARTs, and PI planning cycles, assuming large teams working toward a unified goal. AI, however, decentralizes decision-making in real-time, enabling smaller, more autonomous teams. This shift aligns with emerging development paradigms such as **Cell Development** (see: [Autonomous Coding Agents & The Cell Paradigm](https://www.linkedin.com/pulse/early-visions-autonomous-coding-agents-cell-paradigm-siemens-goddard-pj2ne/)).

🔹 **Continuous Flow Over Fixed Increments**  
AI-driven deployment operates in continuous, automated cycles, challenging SAFe’s fixed iteration model. Traditional planning horizons of months are increasingly obsolete. Amazon, for instance, has been deploying to production every second since 2015—what should the standard be today?

🔹 **From Agile Teams to AI-Augmented Teams**  
The shift isn’t from Agile to Waterfall; it’s from human-driven Agile to AI-augmented, self-organizing teams. If AI can optimize backlogs, resolve dependencies, and facilitate coordination, what role does SAFe’s extensive structure still play?

🔹 **Building a New Stable Core**  
Organizations are moving away from stability through large-scale alignment. Instead, small, independent teams must construct a **stable core** through robust development, deployment, and test automation. SAFe, in its current form, does not adequately prioritize these engineering fundamentals as essential individual skillsets.

## The Future of SAFe in an AI-Driven World

SAFe won’t disappear overnight, but its value proposition is increasingly challenged. The focus is shifting from orchestrating human teams to fostering AI-human collaboration at scale. If SAFe is to remain relevant, it must undergo fundamental changes to align with this new reality.


The emergence of AI-native systems is challenging traditional enterprise models. Does this also signal the decline of SAFe (Scaled Agile Framework)?

Does the End of SaaS Also Mean the End of SAFe?

/images/2025-01-30-does-the-end-of-saas-also-mean-the-end-of-safe.png


## When Organizations Become Their Software

Melvin Conway famously observed that software systems tend to mirror the communication structures of the organizations that create them. But have you noticed the reverse?

Organizations are increasingly reflecting the software they’ve built.

Take a look at how development organizations in global enterprises are structured. Large-scale agile frameworks like SAFe organize teams around legacy SaaS monoliths, embedding rigid workflows and siloed teams into the company’s DNA. These structures, originally meant to streamline development, now shape how companies think, move, and make decisions. And in the age of AI, that’s a problem.

## The Challenge

AI paradigms require flexibility, cross-functional collaboration, and rapid experimentation. Yet many organizations are shackled by software architectures designed for an era of stability, not agility. Instead of accelerating transformation, these outdated structures resist it. The very systems built to support operations end up defining them, limiting adaptability just when AI demands the opposite.

So how do we break free? How can organizations reclaim their ability to evolve without being constrained by legacy software structures?

## Breaking the Pattern

Here are four ways to ensure your organization evolves beyond the constraints of its software and can start to leverage AI effectively:

1️⃣ Embrace Modular Systems

Replace monolithic software with composable architectures that mirror the fluidity AI demands. Think microservices, orchestration layers, and APIs that enable quick adjustments. The goal isn’t just better software—it’s building a foundation for adaptability.

2️⃣ Rethink Processes, Not Just Tools

AI isn’t just another layer in the tech stack—it demands reimagining workflows and decision-making. Break down silos and empower teams with data-driven autonomy. The organizations that thrive in the AI era will be those that treat AI as a core design principle, not a bolt-on feature.

3️⃣ Foster a Learning Culture

Encourage teams to experiment, iterate, and fail forward. AI thrives in environments where curiosity and adaptability are the norm. Make room for exploration, and don’t let rigid structures kill innovation before it starts.

4️⃣ Support the Troublemakers

There is already passion and experience within your teams. Find those who haven’t resigned to the status quo—those who question, push, and challenge assumptions. Task them with small, quick-change programs that create momentum for larger transformation.

## A New Era of Design

In the age of AI, organizations must shape software, not the other way around. By aligning systems with people-first principles and emerging AI capabilities, we can lead innovation rather than chase it.

The question is no longer whether AI will change how we work—it already is. The real question is: Will your organization be defined by its software, or will it design the software that defines it?



The Inverse Conway's Law

/images/2025-01-28-the-inverse-conways-law.png


Chris Fields’ quantum modeling applied to the Free Energy Principle suggests something quietly unsettling. An entangled quantum system keeps an information boundary that is only loosely coupled to its environment. Or, put more simply—strong internal connectivity reduces entropy, increases predictability and makes a system more distinct from everything else.
Which brings us to an unexpected consequence: If ChatGPT can give satisfying answers about your business, you have a serious problem.

## Why Your Knowledge Might Not Be Yours Anymore

Here’s why. If an LLM can confidently describe your strategy, your edge, your secret sauce—it means your internal connectivity is weak. It means the world already knows what you know. And worse, it means that your organization is losing its shape, slipping into the background noise of general knowledge. A weak distinction boundary allows external entropy to creep in, eroding your unique position.

Many businesses fall into this trap without realizing it. The convenience of external knowledge sources, automation, and AI-generated insights comes at a cost: a dilution of internal expertise. When the same answers are available to anyone who asks, what remains as your competitive advantage?

## Strengthening Your Internal Connectivity

So what’s the way out? You must increase internal connectivity. Your processes can’t just be workflows; they need to be a tightly woven, dynamic network. Your data can’t just be stored; it has to move, transform, and mirror the very essence of your intellectual property. Your data must become an extension of your knowledge assets, not just a reflection of past transactions.

This requires a shift from static information repositories to dynamic, evolving knowledge structures. Teams must cultivate an internal knowledge ecosystem that is resilient to external absorption. The key is to transform operational processes into continuously learning systems, where data flows like a circulatory system rather than sitting in isolated silos.

## The Role of Data Meshes in Retaining Organizational Intelligence

This is where Data Meshes come in—not just as analytical structures, but as living, breathing operational streams that bind value creation to data. When done right, they become the foundation for your own knowledge graph, an ontology that isn’t just a byproduct of operations but the very architecture of your intelligence.

A well-designed Data Mesh ensures that knowledge doesn’t just exist but actively evolves with the organization. It aligns data ownership with domain expertise, ensuring that insights are contextually relevant and deeply integrated into the workflow rather than being passively collected.

## How AI Can Work *For* You, Not *Against* You

AI is only as useful as the structure of the knowledge it can reason upon. If your knowledge is just a loose collection of facts already absorbed by public models, AI won’t differentiate you. But if your knowledge is a structured, evolving mesh of proprietary insights, AI can amplify it—helping you reason, anticipate, and act in ways that remain uniquely yours.

The real challenge isn’t whether AI can replace knowledge, but whether organizations can create environments where knowledge grows internally rather than being outsourced to external models. This isn’t about blocking AI; it’s about ensuring that AI works in service of your unique intelligence rather than eroding it.

## Keeping Your Edge in an AI-Driven World

ChatGPT might be able to answer a lot, but it should never be able to answer everything about you. Businesses that rely too heavily on external intelligence without reinforcing their own will find themselves indistinguishable from the rest. The future belongs to those who understand that intelligence isn’t just about having access to knowledge—it’s about creating and structuring it in a way that remains uniquely theirs.


Quantum modeling applied to the Free Energy Principle suggests something quietly unsettling: If ChatGPT can give satisfying answers about your business, you have a serious problem.

Get Connected to Stay Distinctive

/images/2025-01-23-get-connected-to-stay-distinctive.png


Miracles wear off quickly these days. LLM chats are meanwhile everyday business , so we need new toys - the next rush is Agentic AI. Most uses cases and demos we see in the agentic AI world today are simple sequences of steps, mostly broken down to avoid model overload. This is nice but not very impressive. Why all the craze about agentic AI systems? 

💡 The novel promise is that complex processes will not be streamlined to make human work more efficient but will replace human work. This happens by overcoming the "digital barrier", which means, AI competes not with other IT systems about budgets and resources but with the human work budgets, which are a much bigger cost factor in companies today. Helen Edwards of Artificiality wrote an interesting post about this shift. That is where the new gold rush has its origins. 

So, what's happening, and what can we expect? 

💡 In the heart of most modern IT systems of any type is the coded and structured prescription of outcomes to expect. Quick but deterministic. All this is built on a set of digital primitives which start at the binary state of a computer memory cell, combined with a calculater of these states. To run today's IT ecosystems, we built massive stacks and organizational patterns around this binarity. Satya Nadella targeted those stacks as obsolete when he said that SaaS is dead and needs to be replaced now within the new paradigm of "artificial thoughts". 

💡 Agentic AI Systems are yet in their infancy but we see the components emerging. A new operating system is being built. The language spoken is a pidgin of natural language and semi-structural constraints like the pleading "give me JSON output" prompt, or emerging standards how agents call tools (OpenAI's Function Calling), or how all those agents are to be dispatched and synced (e.g. fetch.ai). Agents are the process workers, which need working memory, long-term memory, processing resources (tool access), LLM model access, and communication capabilities. These are the primitives which are under construction in the moment in an exploding open source-driven startup market (many of those relying on the emerging libraries of LangChain and LlamaIndex) , and of course from the big players OpenAI, Google, AWS, Anthropic. 

💡 from a development and operational point of view, this new paradigm is "wasteful" because the hyperautomation carrier is natural language which is not optimized for machine processing. But the mimikry of human behaviour seems currently to be the best bet for getting a grip on the increasing complexity which can not be managed by classic digital technology alone. 

We will see in the next years how that bet paid off. 



Miracles wear off quickly these days. LLM chats are meanwhile everyday business , so we need new toys - the next rush is Agentic AI

Blog Posts