Corebaseit_posts_in_reviews on Corebaseit — POS · EMV · Payments · AI

I Spent Years on Adaptive Filters. I Was Already Training Neural Networks.

contact@corebaseit.com (Vincent Bevia) — Tue, 14 Apr 2026 10:00:00 +0100

I spent years implementing LMS-based equalizers and echo cancellers in telecommunications. Only later did I fully appreciate what I had been doing mathematically: the same family of update rules that powers neural network training today.

Not as a loose analogy — as the same structure of optimization. Widrow and Hoff formalized the Least Mean Squares (LMS) algorithm in 1960 for the Adaline. Rumelhart, Hinton, and Williams scaled related ideas through multi-layer networks with backpropagation in 1986. The vocabulary changed from adaptive filtering to deep learning, but the core idea — adjust parameters in the direction that reduces error, one small step at a time — is continuous across both worlds.

This post is my attempt to make that lineage explicit: what LMS actually is, why it is structurally the same rule as stochastic gradient descent on a linear model, how the engineering trade-offs line up, and why non-stationarity remains the hard problem in both domains.

LMS Is Not a Metaphor for Training — It Is the Algorithm

The LMS update for a linear combiner (FIR filter or single Adaline) is:

$$ \mathbf{w}(n+1) = \mathbf{w}(n) + \mu , e(n) , \mathbf{x}(n) $$

Here (\mathbf{w}(n)) is the weight vector at time (n), (\mathbf{x}(n)) is the input vector (tap-delay line or feature vector), (e(n) = d(n) - y(n)) is the error between the desired response (d(n)) and the output (y(n) = \mathbf{w}^\top(n)\mathbf{x}(n)), and (\mu) is the step size.

That is stochastic gradient descent on the instantaneous squared error (\frac{1}{2}e^2(n)) with respect to (\mathbf{w}). The gradient of (\frac{1}{2}(d - \mathbf{w}^\top\mathbf{x})^2) with respect to (\mathbf{w}) is (-e,\mathbf{x}). Walking in the opposite direction of the gradient (or equivalently, in the direction (+e,\mathbf{x}) when you define the update as above) is exactly the LMS rule.

So if you have ever shipped an LMS equalizer or echo canceller, you have implemented the foundational learning rule that underlies a huge fraction of modern machine learning: small steps proportional to error times input. The notation in Haykin’s Adaptive Filter Theory differs from PyTorch docs; the mathematics does not.

Multi-layer networks add the chain rule (backpropagation) to compute how error propagates to earlier layers, but the local update at a linear layer trained with mean squared error is still the same structural move: adjust weights in proportion to error and activations. Everything else — momentum, Adam, adaptive learning rates — is engineering on top of that spine.

The Engineering Trade-Offs Are the Same Trade-Offs

In telecommunications, the step size (\mu) controls the classic compromise: convergence speed versus steady-state misadjustment. Too large — the filter can diverge or oscillate. Too small — the filter cannot track a fast-fading channel or a moving echo path. Entire chapters of adaptive filtering textbooks are devoted to stability bounds on (\mu) (often expressed in terms of input power and filter length) and to variants that fix the worst-case behavior.

In deep learning, the learning rate (\eta) plays the same role at a higher level: too high and training diverges or chatters around a minimum; too low and you underfit or burn compute without making progress. The community talks about learning-rate schedules, warm-up, and cosine decay — different names for the same instinct: the right step size depends on the landscape and may need to change over time.

Normalized LMS (NLMS) scales the update by the inverse of the input energy (|\mathbf{x}(n)|^2) (with a small regularizer to avoid division by zero). The goal is stable convergence when input power varies — the same motivation that shows up in adaptive optimizers that normalize updates by running statistics of gradients (RMSProp-style normalization is not identical to NLMS, but the intent — tame the step when the signal scale changes — is shared). The DSP community spent decades refining these ideas for real-time hardware; ML rediscovered many of the same pressures when training became unstable at scale.

Non-Stationarity Was Always the Real Problem — and Still Is

Adaptive filters were built for non-stationary environments: multipath fading, time-varying echoes, drifting noise floors. The “true” optimal weights are not fixed; they move. The filter is not supposed to converge once and freeze — it is supposed to track. That mindset is closer to production ML than a static batch fit on a fixed dataset.

Modern systems face the same phenomenon under different labels: distribution shift, concept drift, stale features, changing user behavior, adversarial drift in inputs. The model that was optimal last month is not guaranteed to be optimal this month. Retraining on a schedule, online updates, monitoring, and guardrails are the engineering response — conceptually in the same family as “never assume the channel is static.”

Research on in-context learning in linear models (for example Akyürek et al., 2022) even investigates which learning algorithms are implicitly approximated by transformers under simplified settings — another reminder that the boundary between classical adaptive signal processing and contemporary ML is thinner than course catalogs suggest.

The Bigger Picture

For engineers who came up through telecommunications and signal processing, the move into AI is often described as a career pivot. In my experience, it is closer to a change of vocabulary on top of a continuous mathematical thread: error-driven updates, step-size discipline, stability under non-stationarity, and the centrality of second-order statistics (explicitly in LMS, implicitly in much of modern training).

The boundary between DSP and machine learning was never as sharp as the literature implied. If you understand LMS, you already understand a piece of what every deep learning framework is doing when it steps the weights. The rest is scale, architecture, and tooling — important, but not magic.

References

Widrow, B., & Hoff, M. E. “Adaptive switching circuits.” IRE WESCON Convention Record, 4, 96–104, 1960.
Haykin, S. Adaptive Filter Theory (4th ed.). Prentice Hall, 2002.
Rumelhart, D. E., Hinton, G. E., & Williams, R. J. “Learning representations by back-propagating errors.” Nature, 323, 533–536, 1986.
Akyürek, E. et al. “What learning algorithm is in-context learning? Investigations with linear models.” 2022. arxiv.org/abs/2211.15661

Why Parents Still Matter in the AI Era

contact@corebaseit.com (Vincent Bevia) — Sun, 12 Apr 2026 10:00:00 +0100

For most of us, the first things we learned did not come from a feed or a model. They came from people.

Parents taught us how to speak, how to behave, how to apologize, how to tell right from wrong. Teachers gave structure and discipline. Clergy, mentors, and professors helped shape conscience, meaning, and judgment. Education was never only the transfer of information. It was the formation of character.

That is why a line in the April 2026 issue of IEEE Computer stopped me cold. Nir Kshetri and Jeffrey Voas note that for earlier generations, parents, teachers, clergy, and professors were the primary educators — and that for today’s generation, artificial intelligence and social media are also playing that role.

If you build or deploy AI systems, you already think about accountability, objectives, and who stays in the loop. The same questions apply at home — only the stakes are not latency or uptime. They are who a child becomes.

The Question Is Not Whether AI Can Help

It can. AI can explain a concept several ways, generate study guides, quiz interactively, and return feedback immediately. Research and surveys increasingly show students turning to tools like ChatGPT as a personal tutor — and some parents prefer that option in certain situations, at least for convenience or cost.

But education is not only speed, convenience, or short-term performance.

A system can explain algebra. It does not teach humility. A chatbot can help draft an essay. It does not model integrity in the room with you. An algorithm can tune pacing. It cannot love a child, correct an attitude with patience, or pass on wisdom through lived example.

That is where parental responsibility grows in the age of AI — not shrinks.

The Real Risk: Slow Substitution

The failure mode is not only “the child used ChatGPT.” It is adults gradually outsourcing conversation, mentorship, attention, and judgment.

Helper becomes tutor. Tutor becomes default interlocutor. Somewhere in that slide, information can increase while formation thins out — more answers, less modeling of how to think, disagree, recover from error, or care about someone else’s dignity.

That distinction matters.

Knowledge without judgment is dangerous. Skill without conscience is fragile. Confidence without moral grounding is unstable.

What the Research Actually Emphasizes

Kshetri and Voas are measured. They do not claim AI is inherently harmful to development. They acknowledge benefits and point to models such as Alpha, where AI improves outcomes because it sits inside a structured system — clear goals, human coaching, ethical guardrails.

In other words: AI tends to work best when adults remain clearly in charge of the frame.

That is familiar language if you design systems. Technology is an amplifier. What it amplifies depends on objectives, constraints, and who owns responsibility when something goes wrong. In the home, that owner is still the parent — not the model weights.

What Responsibility Looks Like in Practice

Stay present — attentionally, not only physically. Know which tools your children use and what those tools optimize for (engagement, speed, plausibility — not necessarily wisdom).

Source literacy. Teach that a fluent answer is not always a wise one, and that convenience is not the same as truth. The same lesson you apply when you verify a model’s output at work applies when they paste homework into a chat window.

Effort and understanding. Ensure assistance does not permanently replace the struggle that builds real skill — and that “done” is not the only success metric.

Examples over answers. Children need to see adults who think carefully, act responsibly, admit mistakes, and live by principles they can name. No language model replaces that. No feed transmits it the way daily ordinary life with a trusted adult does.

Formation Is Still the Work of People

AI may become one of the century’s most powerful educational tools. Used well, inside values-driven structure and with humans setting the terms, it can genuinely help how children learn.

But parents are responsible for something larger than grades or throughput.

We are responsible for formation.

If we blur that line, children may grow up surrounded by the most capable systems in history — and still miss the human guidance that mattered most.

Reference

Kshetri, N., & Voas, J. “Parents, Teachers, Clergy, and Professors.” Computer (IEEE Computer Society), April 2026.

Multi-Agent Systems Scale Vertically. They Need to Scale Horizontally.

contact@corebaseit.com (Vincent Bevia) — Fri, 03 Apr 2026 10:00:00 +0100

This post continues the ideas explored in Part I: Super Agents and Multi-Agent Communication and Part II: Swarm Intelligence. Those posts covered how agents coordinate within a workflow. This one asks what happens after the workflow ends.

After spending time with the orchestrator pattern and the swarm pattern, I kept running into the same gap — one that the field has not been honest enough about.

Agents can communicate within a workflow. They can share state, hand off tasks, and coordinate through structured message protocols. I covered all of that in the previous posts, and all of that is solved. What is not solved is this: once the run completes and the agents figure out how to handle a complex workflow, that knowledge stays isolated. The next run starts cold.

That is the vertical scaling trap. And the more I read — across Reflexion, ERL, Letta’s stateful agent work, and Google Research’s recent findings on scaling agent systems — the more I realized this is the most important unsolved problem in multi-agent architecture today.

What Vertical Scaling Actually Means

The industry has concentrated its investment on making individual agents more capable in isolation — longer context windows, stronger reasoning models, richer tool sets, more compute per inference call. This is vertical scaling: more depth, more power, more intelligence concentrated in a single node.

Vertical scaling has delivered real gains. Modern LLM-based agents can handle significantly longer reasoning chains, maintain larger working memories, and invoke more complex tool sequences than agents from two years ago. The benchmark numbers confirm this.

But vertical scaling has a ceiling, and that ceiling is architectural, not computational. No matter how capable a single agent becomes, a system of agents that starts each run from a blank slate cannot accumulate collective intelligence over time. Every execution is, in a meaningful sense, the first time that system has encountered the problem.

That is the definition of a system that does not learn.

The Statefulness Illusion

This was the part that clarified the problem most for me. LLM agents are stateless by design. The model itself has no memory between API calls — every inference starts fresh, bounded by what exists inside the current context window. What looks like agent memory in most production frameworks is actually infrastructure built around the model: conversation history injected into the prompt, vector stores queried at retrieval time, workflow state persisted in an external database.

The agent does not remember. The infrastructure remembers. And the agent only knows what the infrastructure decides to surface at inference time.

This distinction matters because it exposes the scope of what is currently being solved. Stateful agent frameworks — LangGraph, MemGPT/Letta, Amazon Bedrock AgentCore Memory, and others — address continuity within a workflow and within a user session. They do not address what happens between runs, across agent instances, or across different executions of the same workflow by different users.

Each agent run, regardless of the framework, is still largely isolated from the accumulated experience of every run that came before it.

The Horizontal Scaling Problem

Horizontal scaling in multi-agent systems means something different from what the term usually implies in infrastructure. It is not about running more agent instances in parallel — that is a load distribution problem, and it is solved. The horizontal scaling problem I’m describing is about propagating learned competence across agents and across runs.

When I mapped the gap concretely, it looked like this:

Capability	Current State
Agents share state within a run	Solved
Agents communicate within a workflow	Solved
Agent learns within a run (self-reflection)	Partial — Reflexion
Successful strategy propagates to next run	Not solved
Knowledge discovered by one agent available to others	Not solved
Collective intelligence accumulates over time without retraining	Not solved

The bottom three rows represent the horizontal scaling gap. It is not a matter of framework maturity — it is an architectural primitive that does not yet exist in production multi-agent systems.

What the Field Has Built as Workarounds

Research and engineering teams have made partial progress, and it’s worth naming what exists honestly.

Shared episodic memory stores. Agents can write successful reasoning traces or strategy summaries to a vector database that future agent instances retrieve via RAG. This is useful, but the memory is static once written. It does not update based on outcomes, and retrieval quality determines whether the right experience surfaces at the right moment.

Reflexion and its descendants. Reflexion (Shinn et al., NeurIPS 2023) introduced a framework where agents verbally reflect on task feedback and store those reflections in an episodic memory buffer to improve decision-making in subsequent trials — without modifying model weights. This is a genuine step forward, and it’s the work that first made me think seriously about this problem. But Reflexion is fundamentally a within-run or within-session mechanism. The reflective memory does not propagate across agent instances or persist as a shared resource across independent runs.

ExpeL and Experiential Reflective Learning. More recent work, including ExpeL (Zhao et al., 2024) and ERL (2025), extracts reusable heuristics by comparing successful and failed trajectories, then injects the most relevant heuristics into future agent contexts via retrieval. This is directionally correct. ERL reports a +7.8% improvement over a ReAct baseline on complex agentic benchmarks precisely because failure-derived heuristics provide negative constraints that prune ineffective strategies. But even here, the experience pool is curated offline, retrieval is still prompt injection, and the feedback loop is not real-time.

Prompt distillation and fine-tuning. Successful agent runs can generate training data that feeds a fine-tuning pipeline. This is horizontally scalable in principle — the knowledge of one run eventually improves the base model that all agents use. But the feedback loop is slow, expensive, requires human curation, and operates offline. It is not collective learning; it is deferred knowledge consolidation.

Workflow libraries and pattern registries. Teams manually curate successful workflow templates. This is human-mediated knowledge transfer, not agent-mediated. It does not scale.

None of these close the gap. They are engineered workarounds for the absence of a proper horizontal learning primitive.

What Is Actually Missing

The architectural primitive that does not yet exist is a persistent, agent-writable, outcome-weighted knowledge layer — one where agents contribute strategy signals after a run completes, and those signals influence future agent behavior without requiring a full retraining cycle or human curation.

The biological analogy came back to me here from the swarm intelligence research I covered in Part II: pheromone trails in ant colonies are not just a communication mechanism — they are a distributed, incrementally updated knowledge store. Shorter, higher-quality paths accumulate stronger signals through positive feedback. Failed paths evaporate. The swarm’s collective intelligence is encoded in the medium itself, not in any individual. No central controller decides which trails are “good.” The outcome does.

What that looks like for LLM-based multi-agent systems is still an open design problem, but the requirements I’ve been able to identify are:

Outcome-weighted writes. Agent runs that complete successfully contribute to the shared knowledge layer with positive weight; failed runs contribute negative constraints. Both are useful — ERL’s results show that failure-derived heuristics often outperform success-derived ones on search tasks.
Decentralized propagation. The update mechanism cannot require a human in the loop or an offline batch process. Strategy signals need to propagate in something close to real time across agent instances.
Relevance-gated retrieval. Future agents need to surface relevant prior experience without injecting everything into context. This is partially addressed by LLM-based retrieval scoring, but remains unsolved at scale.
No weight updates required. The mechanism needs to operate within the context engineering layer, not through gradient descent. Retraining is too slow and too expensive for real-time collective learning.

Why the Industry Has Not Solved It

The more I thought about it, the more I realized the incentive structure explains the gap more than the technical difficulty does.

Vertical scaling — a bigger model, a stronger benchmark score, a longer context window — has a clear commercial lever. It is attributable to a specific product release and easy to market. Horizontal knowledge propagation is architecturally harder, requires runtime infrastructure that does not exist yet, and the value it generates is distributed across runs and users rather than attributable to a single capability upgrade.

Google Research’s recent work on scaling agent systems found that adding more agents does not consistently improve performance — multi-agent coordination yields substantial gains on parallelizable tasks but can actually degrade performance on sequential workflows. More agents is not the answer. Smarter knowledge transfer is. But that is a harder problem to benchmark and a harder story to sell.

The Architectural Opportunity

The systems that will win over the next two to three years will not be the ones with the largest individual agents. They will be the ones that figure out how to make collective experience accumulate efficiently across runs, across users, and across agent instances — without requiring a human editor or an offline training cycle to make it useful.

This is, in a meaningful sense, the missing layer of agentic AI infrastructure. The orchestration layer exists — I covered it in Part I. The communication protocols exist. The shared state store exists. The swarm coordination patterns exist — I covered those in Part II. What does not exist is a production-grade mechanism for collective learning that operates at runtime.

The research directions are beginning to converge on this problem — Reflexion, ERL, Collaborative Memory — but none has produced a general-purpose primitive that production systems can adopt. That gap is both the honest state of the art and the most interesting open problem in multi-agent architecture today.

References

Letta. “Stateful Agents: The Missing Link in LLM Intelligence.” letta.com
Shinn, N. et al. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. arxiv.org/abs/2303.11366
Rezazadeh, M. et al. “Collaborative Memory: Multi-User Memory Sharing in LLM Agents with Dynamic Access Control.” 2025. arxiv.org/abs/2505.18279
“Experiential Reflective Learning for Self-Improving LLM Agents.” 2025. arxiv.org/abs/2603.24639
Google Research. “Towards a Science of Scaling Agent Systems: When and Why Agent Systems Work.” 2026.
Part I: Super Agents and Multi-Agent Communication — orchestration, structured communication, and the single source of truth
Part II: Swarm Intelligence — The Opposite Architectural Bet — decentralized coordination and emergent intelligence
Reasoning Models and Deep Reasoning in LLMs — the reasoning strategies that power individual agents
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — engineering judgment in the age of autonomous AI systems

Swarm Intelligence: The Opposite Architectural Bet

contact@corebaseit.com (Vincent Bevia) — Sat, 28 Mar 2026 10:00:00 +0100

This is Part II of a two-part series on multi-agent AI architecture. Part I covered the super agent pattern: centralized orchestration, structured communication, and a single source of truth. This post explores the opposite approach.

Everything I described in Part I assumes a central orchestrator that owns workflow visibility and decision authority. Swarm intelligence is the opposite architectural bet — and understanding the contrast changed how I think about multi-agent design.

When I started reading about swarm intelligence after writing the orchestrator post, I expected a niche optimization technique. What I found instead was a fundamentally different philosophy of coordination — one where global competence emerges from local interactions, with no central controller and no global plan. The more I dug in, the more I realized this isn’t just an alternative pattern. It’s a direct challenge to some of the assumptions I laid out in Part I, and understanding where each approach wins (and fails) is what separates a good multi-agent architecture from an overengineered one.

What Is Swarm Intelligence?

Swarm intelligence is the study and engineering of collective behavior that emerges from many simple agents interacting locally, with no central controller and no global plan. Each agent operates on partial information and follows simple local rules. Global-level competence — efficient foraging, optimal routing, adaptive task allocation — emerges from those local interactions rather than being imposed from above.

What struck me about this definition is how directly it inverts the super agent model. In Part I, I described a system where the orchestrator is the only node with full workflow visibility, and specialist agents receive scoped inputs and produce scoped outputs. In a swarm, no agent has full visibility. There is no orchestrator. And yet the collective solves problems that exceed the capability of any individual member.

Three properties define the pattern:

Decentralization. There is no leader node. No single agent has full workflow visibility, and none can issue authoritative commands to others. Coordination is a byproduct of local interaction, not a product of centralized planning. This is the property that makes swarms inherently fault-tolerant — remove any individual agent and the system continues functioning, because no agent was indispensable to begin with.

Self-organization. Coherent global patterns arise spontaneously from local rules. No agent is told “build this structure” or “follow this path.” The structure and the paths emerge from thousands of independent decisions, each one simple, each one local, each one informed only by the agent’s immediate environment. The global order was never specified — it assembled itself.

Emergent intelligence. The collective solves problems that exceed the capability of any individual agent. This is the part that I found genuinely surprising when I started looking at the research: the group is, in a meaningful sense, smarter than its members. Not because the agents secretly share a global model, but because local interactions produce feedback loops that concentrate collective effort on high-quality solutions over time.

From Biology to Algorithms

The canonical biological examples are not just illustrations — they directly inspired the computational methods in use today. Understanding the biology helps explain why the algorithms work.

Ant colonies are the most studied example. An individual ant has no map, no plan, and no knowledge of the colony’s global state. It follows simple rules: wander randomly, and when you find food, return to the nest while depositing pheromone. Other ants are biased toward following stronger pheromone trails. Shorter paths between food and nest get traversed more frequently, accumulate more pheromone, and attract more ants — creating a positive feedback loop that converges on efficient routes. Meanwhile, pheromone evaporates over time, which means abandoned or suboptimal paths fade naturally. The colony’s routing network self-assembles from thousands of individual deposit-and-evaporate decisions.

What I found remarkable is how robust this is. Block a path, and the colony reroutes within minutes — not because any ant “knows” the path is blocked, but because pheromone stops accumulating on the blocked segment and alternative routes gain relative strength. The system adapts to disruption without any agent being aware of the disruption at a global level.

Bee colonies use a different coordination mechanism: the waggle dance. Scout bees evaluate potential food sources or nest sites, then return to the hive and communicate their findings through a dance whose duration and direction encode the distance and quality of the source. Other bees probabilistically follow the more enthusiastic dancers. Over rounds of scouting and reporting, the colony converges on the best available option — a decentralized decision process that has been shown to rival the accuracy of optimal mathematical models.

Bird flocks and fish schools demonstrate a third variant: alignment-based coordination. Each individual follows three simple rules — separation (don’t crowd), alignment (match direction with neighbors), and cohesion (stay close to the group). The stunning visual coherence of a starling murmuration or a sardine ball emerges entirely from these local rules. No bird leads. No fish coordinates. The collective pattern is an emergent property of individual behavior.

These aren’t metaphors. They are the direct inspiration for the algorithms.

The Two Dominant Algorithms

Two metaheuristics dominate applied swarm AI, and both map directly from the biological mechanisms above.

Ant Colony Optimization (ACO)

ACO, introduced by Marco Dorigo in 1992, translates the ant foraging model into a general-purpose optimization algorithm. Artificial agents (“ants”) traverse a solution space — typically modeled as a graph — and deposit virtual pheromone on the edges they traverse. The pheromone strength on each edge influences the probability that subsequent ants will choose that edge. Better solutions accumulate stronger pheromone over time through positive feedback, while evaporation ensures the algorithm doesn’t lock permanently onto early suboptimal solutions.

The algorithm is straightforward:

Initialize pheromone levels uniformly across all edges
Each ant constructs a complete solution by traversing the graph, with transition probabilities biased by pheromone strength and a heuristic desirability function
After all ants complete their tours, update pheromone: deposit proportional to solution quality, evaporate a fixed fraction globally
Repeat for a fixed number of iterations or until convergence

ACO has been applied successfully to the Traveling Salesman Problem, vehicle routing, network routing, job-shop scheduling, and protein folding. What I found interesting from an engineering perspective is that ACO handles dynamic problems well — if the graph changes during execution (a link goes down, a cost changes), the pheromone distribution naturally adapts over subsequent iterations without requiring a restart.

Particle Swarm Optimization (PSO)

PSO, introduced by Kennedy and Eberhart in 1995, takes inspiration from bird flocking and fish schooling rather than ant foraging. Each “particle” in the swarm represents a candidate solution in a continuous search space. Each particle has a position and a velocity, and it maintains two pieces of memory: its own best-known position (pbest) and the global best position found by any particle in the swarm (gbest).

At each iteration, each particle updates its velocity as a weighted combination of three forces:

Inertia — continue in the current direction
Cognitive pull — move toward pbest (the agent’s own best experience)
Social pull — move toward gbest (the collective’s best experience)

The balance between cognitive and social pull determines the exploration-exploitation trade-off. Heavy cognitive pull means particles explore independently; heavy social pull means the swarm converges quickly on the current best. Tuning these weights is the primary design decision in PSO.

PSO is widely used in continuous optimization, neural network training, feature selection, and engineering design optimization. Unlike ACO, PSO operates in continuous space rather than on graphs, which makes it a natural fit for problems where solutions are represented as real-valued vectors.

What I found appealing about both algorithms is their simplicity. The core logic of ACO or PSO fits in a few dozen lines of code. The intelligence doesn’t come from the complexity of the individual agent — it comes from the interaction dynamics of the population.

A Minimal PSO Example

To make this as concrete as I did for the orchestrator pattern in Part I, here’s a minimal PSO implementation. The swarm searches for the minimum of a simple 2D function:

import random

def objective(position: list[float]) -> float:
 x, y = position
 return x ** 2 + y ** 2

class Particle:
 def __init__(self, bounds: list[tuple[float, float]]):
 self.position = [random.uniform(lo, hi) for lo, hi in bounds]
 self.velocity = [random.uniform(-1, 1) for _ in bounds]
 self.best_position = list(self.position)
 self.best_score = objective(self.position)

def run_pso(
 n_particles: int = 20,
 bounds: list[tuple[float, float]] = [(-10, 10), (-10, 10)],
 iterations: int = 50,
 w: float = 0.7,
 c1: float = 1.5,
 c2: float = 1.5,
) -> list[float]:
 particles = [Particle(bounds) for _ in range(n_particles)]
 global_best = min(particles, key=lambda p: p.best_score)
 gbest = list(global_best.best_position)
 gbest_score = global_best.best_score

 for _ in range(iterations):
 for p in particles:
 for i in range(len(bounds)):
 r1, r2 = random.random(), random.random()
 p.velocity[i] = (
 w * p.velocity[i]
 + c1 * r1 * (p.best_position[i] - p.position[i])
 + c2 * r2 * (gbest[i] - p.position[i])
 )
 p.position[i] += p.velocity[i]
 p.position[i] = max(bounds[i][0], min(bounds[i][1], p.position[i]))

 score = objective(p.position)
 if score < p.best_score:
 p.best_score = score
 p.best_position = list(p.position)
 if score < gbest_score:
 gbest_score = score
 gbest = list(p.position)

 return gbest, gbest_score

best_pos, best_score = run_pso()
print(f"Best position: {best_pos}")
print(f"Best score: {best_score}")

Twenty particles, each starting at a random position, each pulled toward its own best experience and the swarm’s collective best. No particle knows the objective function’s landscape. No particle directs the others. Yet within 50 iterations, the swarm converges on the minimum — not because any individual found it deliberately, but because the interaction dynamics between personal memory and social influence concentrate the swarm’s exploration on progressively better regions of the space.

Compare this to the orchestrator pattern from Part I: there, a coordinator explicitly assigned work to specialist agents and tracked the workflow state. Here, there is no coordinator. The “coordination” is an emergent property of the velocity update rule. Both patterns produce useful collective behavior — through fundamentally different mechanisms.

Swarm vs. Orchestrator: The Architectural Trade-Off

This is the comparison I kept coming back to as I read through both bodies of literature:

Property	Super Agent (Orchestrator)	Swarm
Control	Centralized	Decentralized
State visibility	Full (single source of truth)	Partial (local only)
Coordination	Explicit assignment and gating	Emergent from local rules
Failure mode	Orchestrator is a single point of failure	Robust to individual agent loss
Predictability	High — deterministic workflow graph	Lower — emergent behavior
Debuggability	High — inspect the state store	Harder — behavior is a collective property
Best suited for	Complex workflows with strict ordering and accountability	Search, optimization, and exploration under uncertainty

The orchestrator pattern wins when you need auditability, sequential dependencies, and defined handoffs — a software delivery pipeline, a compliance workflow, a multi-step API integration. When someone asks “what happened and why,” you can trace the answer through the state store and the orchestrator’s decision log. That’s essential in regulated domains like payments, healthcare, or finance, where I spend most of my time.

The swarm pattern wins when the problem is fundamentally one of parallel exploration, where no single agent can know the right answer in advance and the solution space is too large for a directed search. Routing optimization, hyperparameter tuning, resource allocation under dynamic constraints, adversarial search — these are problems where the strength of the swarm is that it doesn’t commit to a single path early. It explores broadly, converges gradually, and adapts to changes in the landscape without requiring a central replanning step.

The failure modes are equally instructive. An orchestrator system that loses its coordinator loses everything — the workflow stops, the state becomes ambiguous, and recovery requires restarting from a checkpoint. A swarm that loses 20% of its agents barely notices — the remaining agents continue interacting, and the collective behavior degrades gracefully rather than collapsing. On the other hand, a swarm that converges on a suboptimal solution can be hard to diagnose, because the “decision” was never made by any single agent — it emerged from the collective dynamics, and there’s no decision log to inspect.

The Hybrid: Where Both Patterns Meet

What I found most interesting — and most relevant to real-world systems — is that the best architectures don’t choose one pattern exclusively. They combine both.

The emerging production pattern looks like this: a super agent orchestrates the high-level workflow and enforces policy, while swarm-style sub-networks handle search, ranking, or optimization sub-problems where emergent behavior is an asset rather than a liability.

Consider a concrete example: a multi-agent system for automated code review. The orchestrator (super agent) manages the workflow — receive a pull request, assign analysis tasks, collect results, enforce quality gates, produce a final report. That’s a sequential, auditable pipeline. But within the analysis stage, you might deploy a swarm of lightweight agents, each examining the code from a different angle — style, security, performance, correctness, test coverage — with their findings aggregated through a voting or ranking mechanism rather than a centralized decision. The orchestrator owns the workflow. The swarm owns the search.

This hybrid is not theoretical. It shows up in retrieval-augmented generation (RAG) pipelines where an orchestrator manages the query-retrieve-generate flow while a swarm of retrieval agents explores different index partitions in parallel. It shows up in automated trading systems where a central risk engine enforces position limits while swarm-based signal generators explore the market independently. It shows up in robotics where a planner coordinates high-level task sequences while swarm algorithms handle local path planning and obstacle avoidance.

The architectural insight is that orchestration and emergence are not competing philosophies — they are complementary tools for different layers of the same system. The orchestrator provides structure, accountability, and policy enforcement. The swarm provides exploration, resilience, and adaptive search. Using both, at the right layers, gives you something that neither alone can achieve.

What I Took Away from All of This

Across both posts, the thread that connects everything is that multi-agent AI is fundamentally a systems engineering problem. Whether you’re building a centralized orchestrator with a shared state store or a decentralized swarm with emergent coordination, the design questions are the same ones that distributed systems engineers have been wrestling with for decades: how do agents communicate? Who owns state? How do you handle failure? How do you debug collective behavior?

The super agent pattern gives you control, auditability, and predictability. The swarm pattern gives you resilience, adaptability, and the ability to solve problems that are too large or too dynamic for a directed search. The best systems use both — orchestration where you need accountability, emergence where you need exploration.

If Part I was about understanding how to make agents work together under a coordinator, this post is about understanding when to let agents work independently — and trusting that the collective behavior will be smarter than any individual plan.

The models handle the reasoning. The architecture handles the reliability. And the choice between orchestration and emergence determines the shape of that architecture.

References

Wikipedia. “Swarm Intelligence.” en.wikipedia.org
Vation Ventures. “Swarm Intelligence: Definition, Explanation, and Use Cases.” vationventures.com
Scholarpedia. “Swarm Intelligence.” scholarpedia.org
HPE. “What is Swarm Intelligence?” hpe.com
Ultralytics. “Swarm Intelligence in Vision AI.” ultralytics.com
ScienceDirect Topics. “Swarm Intelligence.” sciencedirect.com
Dorigo, M. “Optimization, Learning and Natural Algorithms.” PhD Thesis, Politecnico di Milano, 1992.
Kennedy, J. & Eberhart, R. “Particle Swarm Optimization.” IEEE International Conference on Neural Networks, 1995.
Part I: Super Agents and Multi-Agent Communication — the orchestrator pattern, communication mechanisms, and a minimal Python implementation
Reasoning Models and Deep Reasoning in LLMs — the reasoning strategies that power individual agents in both patterns
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — engineering judgment in the age of autonomous AI systems

Super Agents and Multi-Agent Communication: Architecture That Actually Scales

contact@corebaseit.com (Vincent Bevia) — Fri, 27 Mar 2026 22:00:00 +0100

This is Part I of a two-part series on multi-agent AI architecture. This post covers centralized orchestration. Part II explores the opposite approach: swarm intelligence.

I’ve been reading a lot about “super agents” lately — and once I got past the marketing noise, I found a genuinely useful architectural pattern underneath.

The term gets thrown around loosely, but the more I dug into it — across AWS documentation, IBM’s multi-agent research, LangGraph’s implementation guides, and a handful of practical engineering write-ups — the more I realized it maps cleanly onto problems that single-model, turn-by-turn systems simply cannot solve reliably: multi-step workflows with branching logic, delegated expertise, and external system integration. The concept is not new — multi-agent coordination has decades of research behind it — but LLMs have made it practically viable in ways that weren’t possible three years ago.

This post is my attempt to organize what I’ve learned: what the term actually means, how agents communicate in practice, and a minimal Python implementation I put together to make the pattern concrete before reaching for a framework.

What Is a Super Agent?

The clearest definition I found across the literature: a super agent is an autonomous AI system capable of interpreting a high-level goal, decomposing it into sub-tasks, orchestrating tools and specialist agents, and executing a multi-step workflow with minimal human intervention. That’s the architectural distinction that separates it from a standard chatbot — a chatbot responds turn-by-turn; a super agent plans, delegates, acts, and adapts.

What struck me when I started pulling the concept apart is how concrete the capabilities actually are:

Decompose goals — translate a high-level objective (“Audit our Q2 pipeline and notify the reps”) into a sequenced set of executable tasks.
Orchestrate tools and sub-agents — coordinate search, code execution, external APIs, CRM writes, and domain-specific agents as a unified workflow.
Maintain long-horizon context — preserve memory of the user, the project state, and intermediate results across multiple reasoning steps.
Act in external systems — send emails, update records, generate documents, and book reservations — not just describe how to do those things.
Support human-in-the-loop — pause for confirmation, accept corrections, and revise plans accordingly.

The framing that resonated most with me is that a super agent functions as a digital teammate that can plan, decide, and act — not a passive assistant that generates single responses.

Do Agents Actually Talk to Each Other?

This was the question that pulled me deeper into the topic. The answer is yes — and the way they do it is where the architecture gets interesting. In multi-agent systems, agents communicate via structured messages to coordinate work, share intermediate results, and negotiate task ownership.

Communication Mechanisms

From what I found, three mechanisms dominate in practice:

Message passing. Agents exchange typed messages (request, result, status, feedback) over a bus, queue, or shared memory store. The message structure includes sender, receiver, intent, payload, and timestamp, so both sides can route and act on messages reliably. This is the most flexible mechanism and the one that most closely resembles traditional distributed systems communication — which, coming from a systems engineering background, immediately made sense to me.

Shared state. Rather than direct peer-to-peer calls, agents read from and write to a single authoritative state object. This is the foundation of LangGraph-style graphs and is the pattern most relevant to in-process agent systems. The state object becomes both the communication channel and the coordination mechanism — agents don’t need to know about each other, only about the state contract.

Natural language over a structured envelope. LLM-based agents can exchange plain-text prompts and responses, but production systems wrap those in a JSON schema or DSL to reduce ambiguity and enable deterministic parsing. The natural language carries the semantic content; the envelope carries the routing and type information that machines need to act on it reliably.

Coordination Patterns

The coordination patterns I kept seeing across the literature include request–response, broadcast, task announcement and bidding, and peer-to-peer collaboration where agents refine each other’s outputs. The coordination role is explicit: either a planner agent delegates to workers, or agents operate in a fully collaborative graph where outputs flow through defined contracts.

What I found particularly useful to think about is how the choice of coordination pattern has direct architectural consequences. A centralized planner is simpler to reason about and debug, but creates a single point of failure. A fully distributed collaboration graph is more resilient but harder to monitor and control. Most production systems seem to land somewhere in between — a planner that delegates to autonomous agents, with guardrails and fallback logic at the orchestration layer.

A Minimal In-Process Pattern

To make this concrete for myself, I put together a minimal example. The cleanest starting point I could find for understanding agent-to-agent communication requires only three components: a shared state object, two agent functions, and a lightweight orchestrator that sequences them.

from dataclasses import dataclass, field
from typing import List, Dict

@dataclass
class State:
 user_goal: str
 messages: List[Dict[str, str]] = field(default_factory=list)
 draft: str = ""
 review: str = ""

def writer_agent(state: State) -> None:
 state.draft = f"Draft for goal: {state.user_goal}"
 state.messages.append({
 "from": "writer",
 "to": "reviewer",
 "type": "draft",
 "content": state.draft,
 })

def reviewer_agent(state: State) -> None:
 incoming = state.messages[-1]["content"]
 state.review = f"Reviewed version of: {incoming}"
 state.messages.append({
 "from": "reviewer",
 "to": "writer",
 "type": "review",
 "content": state.review,
 })

def run_workflow(goal: str) -> State:
 state = State(user_goal=goal)
 writer_agent(state)
 reviewer_agent(state)
 return state

state = run_workflow("Create a short API integration summary")
print(state.messages)
print(state.review)

writer_agent() produces a draft and appends a typed message targeted at the reviewer. reviewer_agent() reads that message and writes its response back into the same structure. Both agents live in the same process, yet the message list enforces a clean protocol boundary — which is exactly what makes the design debuggable and extensible.

Why This Pattern Scales

What I like about this design is that the agents are loosely coupled: they do not invoke each other’s business logic directly; they communicate through state and message contracts. That separation makes it straightforward to insert a supervisor, add retries, inject validation, or introduce checkpointing without rewriting each agent’s core responsibility.

When I later looked at LangGraph, I found this same idea formalized as graph nodes that receive state and return a Command specifying which node runs next and what state updates to apply. The plain Python example above maps directly to START → writer → reviewer → END, with shared state as the communication channel. Building the minimal version first helped me understand what the framework is actually abstracting.

The Super Agent as Orchestrator

One pattern that came up consistently across everything I read: in production multi-agent systems, the super agent is the orchestrator — not another worker. This distinction matters more than it sounds.

The orchestrator does not perform domain work. It decomposes the user goal and assigns sub-tasks to specialist agents. It tracks workflow state, evaluates intermediate results, and decides on next steps, retries, or fallbacks. It enforces policies, cost boundaries, and safety checks at a single control point. Every specialist agent has a scoped responsibility; the orchestrator has workflow-level visibility.

I sketched out two diagrams to think through how this works in practice. The first illustrates a software delivery context: a single Super Agent at the top of the hierarchy delegates to five specialized agents — Requirements, Coder, Refactor, Test, and Documentation — each with a clearly scoped responsibility and no direct coupling to the others.

The second diagram scales the same pattern to a broader engineering context. Here the orchestrator coordinates six agents covering the full stack — Requirements, Architecture, Frontend, Backend, Test, and Security — and what I noticed is that the hierarchy holds regardless of how many specialists you introduce.

What stays constant across both diagrams — and what I think is the key insight — is that the orchestrator is the only node with full workflow visibility. Specialist agents receive scoped inputs and produce scoped outputs. They do not need to know what the other agents are doing. That coordination burden belongs entirely to the super agent.

The practical three-layer production pattern that I kept seeing emerge:

Layer	Role
Orchestrator / super agent	Owns the workflow graph, task assignment, and gate logic
Shared context store	Versioned state or artifacts (DB, files, or structured in-memory state) — the single source of truth
Specialist agents	Read from the store, produce outputs into it, never assume hidden state

This layering felt immediately familiar to me. It mirrors how well-designed distributed systems have always worked: a coordinator with global visibility, workers with local scope, and a shared data layer that keeps everyone honest.

Single Source of Truth: Non-Negotiable

One thing that stood out across nearly every resource I read: multi-agent systems fail when each agent builds its own version of reality. The mature architectures all anchor the entire system to a single source of truth — whether that is a shared in-process state object, a central database, or a versioned artifact store.

The benefits are concrete, and they’re the same benefits I’ve seen in any well-designed distributed system:

Consistency. No diverging world-views across agents running in parallel. When the coder agent writes a function and the test agent writes assertions against it, both are working from the same artifact — not from separate memories of what the specification said.

Debuggability. One place to inspect current state across the entire workflow. When something goes wrong — and in multi-agent systems, something always goes wrong — you need a single pane of glass to understand what each agent saw, what it produced, and where the chain broke.

Clean handoffs. Agents know exactly which fields or artifacts they are responsible for updating. They do not invent state. They do not carry assumptions from a previous run. They read, process, and write — through the central store.

Agents may maintain local working memory or intermediate caches for their own reasoning steps, but they must reconcile through the central truth store before producing outputs that other agents depend on. This is the difference between a system that works reliably and one that works until the agents’ internal models diverge — which, without a single source of truth, they eventually will.

The Bigger Picture

After going through all of this, my takeaway is that the super agent concept is not hype — if you ground it in architecture. The key properties are clear: a goal-decomposing orchestrator, loosely coupled specialist agents, structured inter-agent communication, and a single authoritative state store. The Python pattern in this post is deliberately minimal — I wanted to see the essential reasoning surface before layering on a framework.

If you are building toward a LangGraph or similar implementation, the concepts translate directly: nodes map to agents, edges map to message contracts, and the graph state is your single source of truth. The abstraction is different. The architecture is the same.

The broader realization I came away with is that the hard problem in agentic AI is not making individual agents smarter. It is making multiple agents coordinate reliably — which is, fundamentally, a systems engineering problem. The same principles that make distributed systems work — clear contracts, shared state, scoped responsibility, centralized coordination — are exactly the principles that make multi-agent systems work.

The models handle the reasoning. The architecture handles the reliability.

But centralized orchestration is not the only way to coordinate agents. In Part II, I explore the opposite architectural bet — swarm intelligence — where there is no orchestrator, no global plan, and global competence emerges from local interactions. Understanding when each pattern wins is what makes the difference between a good multi-agent design and an overengineered one.

References

Attention.com. “Introducing Super Agent: Your AI Teammate for Revenue Execution.” 2025.
IBM Think. “What is a Multi-Agent System.” ibm.com
AWS Prescriptive Guidance. “Agentic AI: Multi-Agent Collaboration Patterns.” docs.aws.amazon.com
GeeksforGeeks. “Multi-Agent System in AI.” geeksforgeeks.org
SmythOS. “Agent Communication in Multi-Agent Systems.” smythos.com
ApXML. “Communication Protocols for LLM Agents.” 2025.
DigitalOcean. “Agent Communication Protocols Explained.” digitalocean.com
LangChain. “LangGraph Multi-Agent Systems Overview.” langchain-ai.github.io
LangChain. “Multi-Agent Collaboration Tutorial.” langchain-ai.github.io
VentureBeat. “How Architectural Design Drives Reliable Multi-Agent Orchestration.” 2025.
IBM Community. “Agentic Multi-Cloud Infrastructure Orchestration.” 2025.
Latenode Community. “How Separate Agents Share a Single Memory.” 2025.
Part II: Swarm Intelligence — The Opposite Architectural Bet — decentralized coordination, emergent intelligence, and when to choose swarm over orchestrator
AI Sycophancy — why confident-looking AI output still requires verification, even from autonomous agents
Reasoning Models and Deep Reasoning in LLMs — the reasoning strategies that power individual agents
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — engineering judgment in the age of autonomous AI systems

Data Quality and Accessibility — The Foundation You Can't Skip

contact@corebaseit.com (Vincent Bevia) — Fri, 20 Mar 2026 00:00:00 +0000

Data Quality and Accessibility — The Foundation You Can’t Skip

Part 3 of 4 in the Generative AI Foundations series

We’ve covered the hierarchy and the landscape. Now let’s talk about the thing that actually determines whether any of it works: the data.

You can have the most sophisticated model architecture in the world — but if the data going in is incomplete, inconsistent, or irrelevant, the output will reflect exactly that. Garbage in, garbage out isn’t a cliché in this context; it’s an engineering constraint. High-quality, accessible data is the foundation of any successful AI initiative, and there are six key characteristics that define it.

Completeness

Data should have minimal missing values. Incomplete data leads to biased or inaccurate models. If your training set has gaps, the model will learn to fill those gaps with assumptions — and assumptions at scale become systemic errors.

This is the most common failure mode I see in practice. Teams get excited about model architecture and skip the data audit. Three months later, they’re debugging outputs that make no sense, and the root cause is always the same: missing data that nobody noticed at ingestion time.

Consistency

Data should be uniform across sources. Inconsistent formats, duplicates, or contradictions degrade model performance. When one system records dates as DD/MM/YYYY and another as MM/DD/YYYY, you don’t have a data problem — you have a trust problem.

Consistency gets harder as you scale. A single data source is manageable. Five sources across three departments with different schemas, different update cadences, and different owners? That’s where data engineering earns its keep.

Relevance

Data should be appropriate for the task. Irrelevant data adds noise and reduces model effectiveness. More data is not always better data — what matters is whether the data is aligned with the problem you’re trying to solve.

This is counterintuitive for people coming from a “big data” mindset. The instinct is to throw everything at the model and let it figure out what matters. But in practice, curated, task-specific datasets consistently outperform massive, unfocused ones. Quality beats quantity every time.

Availability

Data must be readily accessible when needed for training and inference. This means thinking about data pipelines, storage architecture, and latency. The best dataset in the world is useless if it takes 48 hours to query.

Availability isn’t just a storage problem — it’s an architecture problem. Where does the data live? How is it partitioned? What’s the access pattern? Can your training pipeline read it at the throughput it needs? These are the questions that separate a proof of concept from a production system.

Cost

Data acquisition, storage, and processing all carry costs. Balance data quality needs against budget constraints. There’s always a trade-off between the ideal dataset and what’s economically viable at scale.

This is where real-world engineering meets textbook theory. Yes, you want complete, consistent, relevant data — but you also have a budget. The art is knowing where to invest in data quality and where “good enough” genuinely is good enough. Not every use case needs six-nines data quality.

Format

Data must be in the proper format for the intended use. Conversion, cleaning, and transformation may be required. Raw data is rarely model-ready — the ETL pipeline that sits between your data lake and your training job is where much of the real engineering happens.

Format issues are boring until they’re not. A single encoding mismatch, a rogue null character, a truncated field — any of these can silently corrupt your training data and produce a model that looks fine in evaluation but fails catastrophically in production.

The bottom line: Data quality isn’t a nice-to-have. It’s a prerequisite. Every hour you invest in data preparation saves you ten hours of debugging model outputs later.

Next in the series: ML Lifecycle Stages

Vincent Bevia — corebaseit.com

ML Lifecycle Stages — The Cycle That Never Stops

contact@corebaseit.com (Vincent Bevia) — Fri, 20 Mar 2026 00:00:00 +0000

ML Lifecycle Stages — The Cycle That Never Stops

Part 4 of 4 in the Generative AI Foundations series

We’ve covered the hierarchy, the landscape, and the data. Now let’s close the loop with the ML lifecycle itself — because building a model is not a one-time event. It’s a cycle. And understanding that cycle is critical, because it’s not linear — it’s iterative.

Models degrade. Data drifts. Requirements change. The cycle runs continuously, and each stage feeds back into the others. If you treat model deployment as the finish line, you’ve already lost.

Here’s how it breaks down, with the corresponding Google Cloud tooling at each step.

1. Data Ingestion and Preparation

The process of collecting, cleaning, and transforming raw data into a usable format for analysis or model training. This is where most of the unglamorous but essential work happens — data engineers will tell you that 80% of any ML project is spent here, and they’re not exaggerating.

This stage is where data quality matters most. Every characteristic we discussed in the previous post — completeness, consistency, relevance, availability, cost, format — comes into play right here. Get this stage wrong, and everything downstream inherits the debt.

Google Cloud Tools: BigQuery for data warehousing, Dataflow for data processing pipelines, and Cloud Storage for raw data storage.

2. Model Training

The process of creating your ML model using data. The model learns patterns and relationships from the prepared dataset. This is the compute-intensive stage where your infrastructure investment pays off — or doesn’t.

Training is where the infrastructure layer from our landscape discussion becomes tangible. You need GPUs, TPUs, or both. You need enough compute to iterate quickly, because model training is inherently experimental — you won’t get the architecture, hyperparameters, or data splits right on the first try.

Google Cloud Tools: Vertex AI for managed training, AutoML for no-code model training, and TPUs/GPUs for accelerated computation.

3. Model Deployment

Making a trained model available for use in production environments where it can serve predictions. This is the bridge between “it works in a notebook” and “it works at scale for real users.”

Deployment is where latency, throughput, and reliability become the primary concerns. A model that takes 30 seconds to return a prediction might be fine for batch processing, but it’s useless for a real-time customer-facing application. The deployment architecture has to match the serving requirements — and those requirements are almost always more demanding than what you tested in development.

Google Cloud Tools: Vertex AI Prediction for serving endpoints and Cloud Run for containerised model serving.

4. Model Management

Managing and maintaining your models over time, including versioning, monitoring performance, detecting drift, and retraining. This is the stage most teams underestimate.

A model that was 95% accurate at launch can degrade to 70% within months if nobody’s watching the metrics. The world changes. Customer behaviour shifts. New data patterns emerge that the model has never seen. Continuous monitoring and retraining pipelines are not optional — they’re operational necessities.

This is also where scaffolding proves its value. The guardrails, logging, and observability infrastructure you built during development become your early warning system in production. Without them, you’re flying blind.

Google Cloud Tools: Vertex AI Model Registry, Vertex AI Model Monitoring, Vertex AI Feature Store, and Vertex AI Pipelines.

The Cycle Continues

The arrow from Model Management loops back to Data Ingestion. That’s not a diagram convenience — it’s the reality of production ML. Monitoring reveals drift, drift triggers retraining, retraining requires fresh data, fresh data requires ingestion and preparation, and the cycle begins again.

The teams that succeed with ML in production are the ones that design for this cycle from day one. They don’t treat it as four sequential steps; they treat it as a continuous loop with automation at every transition point.

The bottom line: The ML lifecycle is not build-once-deploy-forever. It’s a living system that requires continuous investment in data, compute, monitoring, and iteration. Plan for the loop, not just the launch.

References

Google Cloud — Generative AI on Vertex AI Documentation. https://docs.cloud.google.com/vertex-ai/generative-ai/docs
Google Cloud — Generative AI Beginner’s Guide. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/overview
Google Cloud — Generative AI Leader Certification. https://cloud.google.com/learn/certification/generative-ai-leader
Google Cloud Skills Boost — Generative AI Leader Learning Path. https://www.skills.google/paths/1951

This is the final post in the Generative AI Foundations series. Read the full series: Part 1: The AI Hierarchy · Part 2: The Gen AI Landscape · Part 3: Data Quality

Vincent Bevia — corebaseit.com

The AI Hierarchy — From Broad to Specific

contact@corebaseit.com (Vincent Bevia) — Fri, 20 Mar 2026 00:00:00 +0000

The AI Hierarchy — From Broad to Specific

Part 1 of 4 in the Generative AI Foundations series

Let’s start with the thing that trips up more people than it should: the terminology.

AI, Machine Learning, Deep Learning, Generative AI — these terms get thrown around interchangeably in boardrooms, blog posts, and LinkedIn hot takes. But they’re not the same thing. Each is a subset of the one above it, and understanding the nesting matters. If you’re going to lead AI initiatives, architect AI-powered systems, or even just have an informed opinion, you need to get the hierarchy right.

Artificial Intelligence (AI)

The broadest concept. AI refers to any system designed to mimic human intelligence — perception, reasoning, decision-making, language understanding. It’s the umbrella term that encompasses everything below it. Rule-based expert systems from the 1980s? That’s AI. A modern LLM generating code? Also AI. The term is intentionally wide, and that’s by design — it has to be, because the field has been reinventing itself every decade since Turing.

Machine Learning (ML)

A subset of AI. Rather than being explicitly programmed with rules, ML systems learn from data to perform specific tasks. You give them examples, they find patterns, and they improve with more data. Supervised, unsupervised, reinforcement learning — all fall under this banner.

The key shift here is philosophical as much as technical: instead of telling the machine how to solve a problem, you show it examples of solved problems and let it figure out the rest. That single idea changed everything.

Deep Learning

A subset of ML. Deep learning uses neural networks with multiple layers (hence “deep”) to learn increasingly abstract representations of data. This is what powers image recognition, speech synthesis, and the transformer architectures behind modern language models.

The depth of the network is what gives it the capacity to learn complex, hierarchical features. A shallow network might learn edges in an image; a deep network learns edges, then textures, then shapes, then objects, then scenes. Each layer builds on the one below it — sound familiar?

Generative AI

The most specific layer. Generative AI is the subset of deep learning focused on creating new content — text, images, audio, video, code. This is where LLMs like Gemini, Claude, and GPT live.

The key distinction: traditional ML classifies or predicts; generative AI produces. It doesn’t just recognise a cat in a photo — it can generate a photo of a cat that never existed. That shift from classification to creation is what makes this moment in AI feel fundamentally different from everything that came before.

Natural Language Processing (NLP)

NLP sits alongside this hierarchy as a cross-cutting discipline. It’s the field focused on understanding and generating human language, and it draws from every layer — from rule-based AI (early chatbots) through ML (sentiment analysis) to deep learning and generative AI (modern LLMs). It’s not a layer in the pyramid; it’s a capability that runs through all of them.

Remember: AI → Machine Learning → Deep Learning → Generative AI. Know the hierarchy: broad to specific.

Next in the series: The Generative AI Landscape — A Layered View

Vincent Bevia — corebaseit.com

The Generative AI Landscape — A Layered View

contact@corebaseit.com (Vincent Bevia) — Fri, 20 Mar 2026 00:00:00 +0000

The Generative AI Landscape — A Layered View

Part 2 of 4 in the Generative AI Foundations series

Now that we’ve established the hierarchy — what AI, ML, Deep Learning, and Gen AI actually are — let’s look at how the Gen AI ecosystem is structured as a working system. Because knowing the theory is one thing; understanding the architecture is what lets you build on it.

The Gen AI landscape is a stack. Five layers, each dependent on the one below it, with value flowing upward.

Infrastructure

At its foundation, the Gen AI stack is an infrastructure play. We’re talking about the raw computing muscle — GPUs, TPUs, high-throughput servers — along with the storage and orchestration software needed to train and serve models at scale. Without this layer, nothing else exists.

Google Cloud’s AI-optimised infrastructure includes custom TPUs (Tensor Processing Units), high-performance GPUs, and the Hypercomputer architecture designed specifically for AI workloads.

Business Implication: Organizations don’t need to invest in expensive on-premises hardware. Cloud infrastructure provides scalable, pay-as-you-go access to AI computing power.

Models

Sitting on top of that infrastructure is the model itself: a complex algorithm trained on massive datasets, learning statistical patterns and relationships that allow it to generate text, translate languages, answer questions, and produce content that, at its best, feels indistinguishable from human output. The model is the engine, but an engine alone doesn’t get you anywhere.

This layer includes foundation models (Gemini, Gemma, Imagen, Veo), open-source models, and third-party models available through platforms like Vertex AI Model Garden.

Business Implication: Organizations can choose from pre-built models (reducing time to market) or train custom models. Model Garden provides access to 150+ models, giving flexibility across use cases.

Platform

That’s where the platform layer comes in. Think of it as the middleware — APIs, data management pipelines, deployment tooling — that bridges the gap between a trained model and the software that actually consumes it. It abstracts away the infrastructure complexity and gives developers a clean interface to build on.

Vertex AI is Google Cloud’s unified ML platform for this layer, providing tools for the entire ML workflow: build, train, deploy, and manage.

Business Implication: Platforms abstract away infrastructure complexity, enabling teams to focus on building AI solutions rather than managing servers. Low-code/no-code tools democratise access to AI.

Agents

Next, the agent. This is where things get interesting. An agent is a piece of software that doesn’t just call a model — it reasons over inputs, selects tools, and iterates toward a goal. It’s the autonomous decision-making layer, and it’s the frontier everyone is racing toward right now.

Agents consist of a reasoning loop, tools, and a model. They can be deterministic (predefined paths), generative (LLM-powered natural language), or hybrid (combining both). Examples include customer service agents, code agents, data agents, and security agents.

Business Implication: Agents represent the next evolution of AI applications, capable of autonomous task completion. They can significantly reduce human workload in customer support, data analysis, and software development.

Applications

Finally, at the top of the stack, sits the Gen-AI-powered application — the user-facing layer. This is what end users actually see and interact with. It’s the product surface that translates all the layers beneath it into something useful, intuitive, and accessible.

Examples include the Gemini app, Gemini for Google Workspace, and custom enterprise applications built with Vertex AI.

Business Implication: Applications deliver the tangible business value of AI. They translate the underlying technology into tools that employees, customers, and partners can use directly.

The Missing Piece: Scaffolding

But here’s the thing most people miss: none of these layers work in isolation. What connects them — what makes the whole stack operational — is scaffolding.

Scaffolding is the surrounding code, orchestration logic, and glue infrastructure that wraps around a foundation model to turn a raw API call into a functioning system. We’re talking about prompt templates, memory management, tool routing, output parsing, guardrails, retry logic, error handling — everything that sits between “call the model” and “deliver a reliable result to the user.”

Without scaffolding, you have a model that can generate text. With scaffolding, you have an application that can reason, recover from errors, maintain context across turns, and chain multiple steps together toward a goal. It’s what makes agents actually work in production.

If you’re an engineer, scaffolding is where you’ll spend most of your time. If you’re a leader, it’s the part of the stack you need to budget for — because the model is the easy part. Making it reliable, safe, and operational at scale? That’s scaffolding.

Remember the five layers bottom-to-top: Infrastructure → Models → Platforms → Agents → Applications. Each layer depends on the one below it, and the value flows upward.

Next in the series: Data Quality and Accessibility

Vincent Bevia — corebaseit.com

Reasoning Models and Deep Reasoning in LLMs: Chain-of-Thought, Tree of Thoughts, and Test-Time Compute

contact@corebaseit.com (Vincent Bevia) — Sat, 14 Feb 2026 20:00:00 +0100

After reading Wei et al.’s work on Chain-of-Thought, the Tree of Thoughts paper from Princeton, and several recent studies on test-time compute scaling, I wanted to organize what I learned about how reasoning actually works — and doesn’t work, as of today — in large language models.

Language models don’t reason. Not in the way humans do. They predict the next token based on patterns learned from training data. But something interesting happens when you force them to show their work: the outputs get dramatically better. Not because the model suddenly “thinks” — but because the structure of the prompt shapes the computation in ways that produce more accurate results.

This post covers the three major strategies for eliciting reasoning behavior from LLMs: Chain-of-Thought prompting, Tree of Thoughts, and Test-Time Compute Scaling. These are not incremental prompt tricks. They represent a shift in how we architect interactions with language models — from single-shot question-answer to structured, multi-step inference pipelines.

Chain-of-Thought Prompting: Forcing the Model to Show Its Work

Chain-of-Thought (CoT) prompting was introduced by Wei et al. at Google Research in 2022. The idea is deceptively simple: instead of asking the model for a final answer directly, you provide examples that include intermediate reasoning steps — and the model learns to generate its own.

How It Works

Standard prompting:

Q: If a store has 23 apples and sells 17, how many remain?
A: 6

Chain-of-Thought prompting:

Q: If a store has 23 apples and sells 17, how many remain?
A: The store starts with 23 apples. It sells 17. 23 - 17 = 6. The store has 6 apples remaining.

The difference looks trivial. The performance difference is not.

Why It Works

When the model generates intermediate steps, it effectively decomposes a complex problem into simpler sub-problems that it can solve sequentially. Each intermediate token generated becomes part of the context for the next prediction. The model doesn’t “plan” — it creates a chain of computations where each step constrains and informs the next.

Wei et al. demonstrated that CoT prompting with PaLM (540B parameters) achieved state-of-the-art accuracy on the GSM8K math benchmark, surpassing even fine-tuned GPT-3 with a verifier. The gains were significant across arithmetic reasoning, commonsense reasoning, and symbolic reasoning tasks.

The Critical Caveat: Scale Dependency

CoT prompting only works reliably in large models. In smaller models (below roughly 100B parameters), chain-of-thought prompting often produces plausible-looking but incorrect reasoning chains. The model generates steps that look logical but contain errors — and because the steps look coherent, these errors are harder to detect than a simple wrong answer.

This is an important architectural consideration: if you’re building a system that relies on CoT reasoning, model size is not optional. Using CoT with an undersized model doesn’t just degrade gracefully — it can actively mislead.

Self-Consistency: Majority Voting Over Reasoning Paths

A natural extension of CoT, introduced by Wang et al. at Google Brain (ICLR 2023), is Self-Consistency. The insight: for any complex problem, there are usually multiple valid reasoning paths that arrive at the same correct answer.

How It Works

Sample multiple reasoning paths. Instead of generating a single chain-of-thought with greedy decoding, sample 5, 10, or 40 diverse reasoning chains using temperature sampling
Extract the final answer from each chain. Ignore the intermediate reasoning — just collect the answers
Majority vote. The most common answer across all sampled chains is selected as the final output

Why It Matters

Self-Consistency treats the reasoning chain as a stochastic process rather than a deterministic one. Any single chain might contain errors. But if you sample enough chains, the correct answer tends to appear more frequently than any specific incorrect answer — because there are many ways to reason correctly, but errors tend to be more random and distributed.

The empirical results are substantial: +17.9% on GSM8K, +11.0% on SVAMP, +12.2% on AQuA. These are large gains from a technique that requires no additional training — only more inference-time computation.

The trade-off is direct: you’re spending N times the compute for significantly higher accuracy. Whether that trade-off is worth it depends on the cost of being wrong.

Tree of Thoughts: Deliberate Search Over Reasoning Space

Chain-of-Thought is linear. You generate one chain, step by step, left to right. If a reasoning step goes wrong early, everything downstream is compromised. There’s no backtracking, no exploration of alternatives.

Tree of Thoughts (ToT), introduced by Yao et al. at Princeton (NeurIPS 2023), addresses this by turning reasoning into a search problem.

How It Works

Instead of generating a single linear chain, ToT:

Decomposes the problem into intermediate “thoughts” — coherent reasoning units (a sentence, a paragraph, a partial solution)
Generates multiple candidate thoughts at each step — branching the reasoning tree
Evaluates each candidate — using the model itself to assess which thoughts are most promising
Searches the tree — using breadth-first search (BFS) or depth-first search (DFS) to explore the most promising paths
Backtracks when needed — abandoning dead-end reasoning paths and exploring alternatives

The Results Are Striking

On the Game of 24 (a mathematical reasoning task), GPT-4 with standard CoT prompting achieved 4% success. With Tree of Thoughts: 74%. That’s not a marginal improvement — it’s a qualitative shift in capability.

The Engineering Reality

ToT is powerful but expensive. Each “thought” evaluation requires a model call. A tree with branching factor 3 and depth 5 requires dozens to hundreds of inference calls per problem. For latency-sensitive applications, this is prohibitive. For high-stakes decisions where accuracy matters more than speed — architecture reviews, certification analysis, complex debugging — the trade-off may be worth it.

There’s also a deeper point: ToT demonstrates that the reasoning bottleneck is often in the inference strategy, not the model itself. The same model (GPT-4) goes from 4% to 74% accuracy by changing how it explores the problem space. The weights are identical. The architecture of the interaction is what changed.

Test-Time Compute Scaling: Spending More Compute Where It Matters

The most recent evolution in reasoning strategies is Test-Time Compute Scaling (TTS) — the principle behind OpenAI’s o1 and o3 models, and an increasingly active area of open-source research.

The idea: instead of fixing the computation budget at inference time, allocate more compute to harder problems. Let the model “think longer” when the problem demands it.

How It Works

TTS models are trained to produce extended reasoning traces before committing to a final answer. The model generates an internal chain-of-thought — sometimes hundreds or thousands of tokens — working through the problem step by step before producing its output.

Two key mechanisms:

Sequential scaling: The model generates longer reasoning chains for harder problems. More tokens = more intermediate computation = (in theory) better answers. This is what o1 does internally.

Parallel scaling: Sample multiple independent reasoning attempts and select the best one — either through majority voting (like Self-Consistency) or through a learned verifier that scores each attempt.

What the Research Shows

Recent large-scale studies reveal important nuances that temper the initial enthusiasm:

No single strategy universally dominates. A study spanning 30+ billion tokens across eight open-source models (7B–235B parameters) found that optimal TTS strategies depend on problem difficulty, model size, and trace length. There is no one-size-fits-all approach.

Longer chains don’t always help. Research on o1-like models (QwQ, DeepSeek-R1, LIMO) found that correct solutions are often shorter than incorrect ones. The models’ self-revision capabilities in longer chains frequently degrade performance — the model talks itself out of a correct answer. This is a direct challenge to the assumption that “more thinking = better answers.”

Parallel beats sequential in many cases. Sampling multiple independent solutions achieves better coverage and scalability than letting a single chain run longer. This has practical implications: it’s often more effective to generate 10 short reasoning attempts and vote than to generate one very long chain.

Simple methods can be surprisingly effective. The s1 model demonstrated that fine-tuning on just 1,000 curated reasoning examples, combined with budget forcing (controlling how long the model thinks via prompting), exceeded o1-preview on competition math by up to 27%. Massive training budgets are not always necessary.

The Hierarchy of Reasoning Strategies

These techniques form a natural progression in complexity and capability:

Strategy	Mechanism	Compute Cost	Best For
Standard prompting	Direct question → answer	1x	Simple factual queries
Chain-of-Thought	Linear step-by-step reasoning	1x (longer output)	Arithmetic, multi-step logic
Self-Consistency	Multiple CoT chains + majority vote	Nx (N samples)	High-stakes decisions where accuracy matters
Tree of Thoughts	Branching search with evaluation and backtracking	10–100x	Complex planning, search problems
Test-Time Compute Scaling	Dynamic compute allocation per problem	Variable	Hard reasoning, competition-level problems

Each level trades compute for accuracy. The engineering question is always: what’s the cost of being wrong?

What This Means for Engineers

These Are Architectural Decisions, Not Prompt Tricks

Choosing between CoT, Self-Consistency, ToT, and TTS is an infrastructure decision. It affects latency, cost, reliability, and the failure modes of your system. Treat it like choosing a database or a caching strategy — not like choosing a font.

Reasoning Quality Is Bounded by Verification

All of these strategies produce more confident-looking output. That makes verification more important, not less. A model that generates a 500-token reasoning chain with a wrong conclusion is harder to catch than one that outputs a single wrong answer. The reasoning chain creates an illusion of rigor.

If you’re in a regulated domain — payments, medical, legal — you need to architect verification into the pipeline, not just trust that more reasoning steps equals more accuracy.

The Model Is Not Reasoning — It’s Computing

This is worth repeating. These techniques improve output quality by structuring computation, not by enabling understanding. The model doesn’t “know” whether its intermediate steps are correct. It doesn’t have beliefs or intentions. It’s generating tokens that are statistically likely given the preceding context.

This isn’t a philosophical quibble. It has practical engineering consequences: the model can generate a perfectly structured, internally consistent reasoning chain that reaches a confidently stated wrong answer. The chain looks logical. The conclusion is wrong. And the better the reasoning strategy, the more convincing the wrong answers become.

Build for verification. Not for trust.

References

Wei, J. et al. “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.” NeurIPS 2022. arxiv.org/abs/2201.11903
Wang, X. et al. “Self-Consistency Improves Chain of Thought Reasoning in Language Models.” ICLR 2023. openreview.net
Yao, S. et al. “Tree of Thoughts: Deliberate Problem Solving with Large Language Models.” NeurIPS 2023. arxiv.org/abs/2305.10601
“The Art of Scaling Test-Time Compute for Large Language Models.” 2025. arxiv.org/abs/2512.02008
Muennighoff, N. et al. “s1: Simple Test-Time Scaling.” 2025. arxiv.org/abs/2501.19393
“Revisiting the Test-Time Scaling of o1-like Models.” ACL 2025. aclanthology.org
The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — engineering judgment in the age of AI reasoning systems
Prompt Engineering for POS — practical CoT applications in payment systems
AI Sycophancy — why confident-looking AI output still requires verification

Payment Tokenization: How Tokens Replace PANs Across the Payment Chain

contact@corebaseit.com (Vincent Bevia) — Sat, 14 Feb 2026 18:00:00 +0100

Every time you tap your phone at a terminal, add a card to an online merchant, or set up a recurring subscription, the system doesn’t use your actual card number. It uses a token — a substitute value that looks like a PAN, routes like a PAN, but carries no exploitable value if intercepted.

Tokenization is one of those mechanisms that sounds simple on the surface but has deep architectural implications across the entire payment chain — from the terminal to the acquirer, through the network, and back to the issuer. Understanding how it works, and how the different token types differ, is essential for anyone building or operating payment systems.

What Is Payment Tokenization?

Tokenization replaces sensitive payment data — primarily the Primary Account Number (PAN) — with a non-sensitive substitute value (the token) that has no exploitable meaning outside the system that generated it.

The critical distinction from encryption: tokens cannot be mathematically reversed to recover the original PAN. There is no key, no algorithm, no formula that maps a token back to the card number. The only way to de-tokenize is to look up the mapping in the token vault — a secured, access-controlled database maintained by the Token Service Provider.

This is a fundamental architectural difference. Encryption is reversible by design. Tokenization is not. If an attacker compromises a system that stores tokens, they get values that are useless outside that specific context.

Standards Framework

Tokenization in payments is governed by a small number of key specifications:

Standard Body	Specification	Purpose
EMVCo	EMV Payment Tokenisation Specification	Defines the global framework for payment tokens usable across the payment ecosystem — issuer → acquirer → networks
PCI SSC	Token Service Provider (TSP) Standard	Security requirements for entities that generate and issue EMV payment tokens
PCI SSC	Tokenization Product Security Guidelines	Guidance for vendors building tokenization products to help merchants reduce card data storage

The EMVCo specification is the one that matters most architecturally. It defines how tokens are provisioned, how they flow through the payment network, and how they’re de-tokenized at the point where the issuer needs the real PAN for authorization.

Token Types in the Payments Ecosystem

Not all tokens are the same. Three distinct types serve different purposes at different points in the payment chain:

1. Payment Tokens (EMVCo)

These are domain-specific tokens issued by the card schemes (Visa, Mastercard) and tied to a specific device, wallet, or merchant. They are usable across the entire payment chain — from terminal to acquirer to network to issuer.

When you add a card to Apple Pay or Google Pay, the scheme’s Token Service Provider generates a payment token that replaces your PAN. That token is provisioned into the device’s secure element or TEE, and used for every transaction. The terminal, acquirer, and network all process the token. Only the TSP and issuer know the mapping back to the real PAN.

Key characteristics:

Scheme-issued and scheme-routed
Tied to a specific domain (device, merchant, channel)
Full lifecycle management: provisioning, suspension, resumption, deletion
Carries its own cryptographic credentials for transaction authorization

2. Issuer Tokens (Virtual Card Numbers)

Created by card issuers for specific use cases — one-time-use virtual cards, limited-spend cards, or cards scoped to a single merchant. These are essentially new PANs issued by the bank that map back to the underlying account.

Key characteristics:

Issuer-generated, not scheme-generated
Often used for e-commerce, subscription management, or corporate expense control
Can have spending limits, expiration rules, or merchant restrictions
The network processes them as regular PANs — the “tokenization” is invisible to acquirers

3. Acquiring Tokens

Merchant-specific tokens generated after authorization to replace the PAN in the merchant’s systems. These are used for storage, refunds, and recurring billing without the merchant needing to retain the actual card number.

Key characteristics:

Generated by the acquirer or payment gateway
Scoped to a single merchant — cannot be used for new authorizations at other merchants
Primary purpose: reduce PCI DSS scope by removing PANs from merchant environments
The acquirer maintains the token-to-PAN mapping

How EMVCo Payment Tokens Flow

The EMVCo tokenization architecture involves several participants:

Token Requestor (TR): The entity that requests token provisioning — typically a wallet provider (Apple, Google), a merchant, or a payment facilitator.

Token Service Provider (TSP): The scheme-operated service that generates tokens, maintains the vault, and handles de-tokenization. Visa operates VTS (Visa Token Service), Mastercard operates MDES (Mastercard Digital Enablement Service).

Token Vault: The secure database mapping tokens to PANs. Access is strictly controlled and audited.

Provisioning Flow

Cardholder adds a card to a digital wallet
The wallet (Token Requestor) sends the PAN to the TSP
The TSP validates the card with the issuer (ID&V — Identification and Verification)
The issuer approves or declines the tokenization request
The TSP generates a token and associated cryptographic keys
The token and keys are provisioned into the device’s secure element or TEE
The original PAN is never stored on the device

Transaction Flow

Cardholder taps the device at a terminal
The device generates a transaction cryptogram using the token and per-transaction keys
The terminal receives the token (not the PAN) and routes it through the acquirer
The acquirer forwards the token to the network
The TSP de-tokenizes: maps the token back to the real PAN
The issuer receives the PAN and authorizes the transaction
The response flows back through the chain — the merchant and acquirer only ever see the token

Major Tokenization Platforms

Visa Token Service (VTS)

Substitutes card numbers with tokens for digital commerce, enabling secure mobile wallet provisioning, in-app payments, and recurring payments. VTS handles lifecycle management including token suspension (e.g., when a device is reported lost) and token updates (e.g., when a card is reissued with a new expiry date).

Mastercard Digital Enablement Service (MDES)

Mastercard’s equivalent platform, providing tokenization for mobile wallets, e-commerce, and IoT devices. MDES supports the same lifecycle operations and integrates with issuers for real-time ID&V during provisioning.

Both platforms are TSPs under the EMVCo framework. They generate tokens in the scheme’s BIN range, ensuring tokens route correctly through the existing payment network infrastructure without requiring changes to acquirer or issuer authorization systems.

Tokenization vs. Encryption: The Architecture Decision

Aspect	Tokenization	Encryption
Reversibility	Not mathematically reversible — requires vault lookup	Mathematically reversible with the correct key
Key management	No keys — the mapping is a database operation	Requires secure key lifecycle management
Format	Token looks like a PAN (same length, passes Luhn check)	Ciphertext — different format, different length
PCI scope reduction	Significant — systems handling only tokens are out of PCI CDE scope	Limited — encrypted PANs are still considered cardholder data
Use case	Storage, routing, recurring billing	Transport-layer protection (TLS), field-level encryption

In practice, most payment architectures use both: encryption protects data in transit (DUKPT, TLS), while tokenization protects data at rest and reduces PCI scope.

Tokenization in POS and SoftPOS Architectures

For POS engineers, tokenization intersects with the terminal architecture at several points:

Mobile wallet transactions (Apple Pay, Google Pay): The terminal receives a payment token, not a PAN. The EMV data includes the token and a transaction-specific cryptogram. The terminal doesn’t need to know it’s processing a token — the flow is transparent.

Merchant token storage: After a successful transaction, the acquirer or gateway may return an acquiring token that the merchant stores for refunds, returns, or loyalty linking. This eliminates the need for the POS system to store PANs.

SoftPOS and Tap-to-Phone: Tokenization is particularly important in SoftPOS architectures where the payment application runs on a COTS device. The combination of EMVCo payment tokens (on the cardholder’s device) and acquiring tokens (in the merchant’s backend) means PANs never touch the merchant’s phone — a critical factor for MPoC compliance.

Recurring and card-on-file: For merchants offering subscriptions or stored payment methods, scheme tokens with card-on-file domain restrictions enable recurring billing without storing actual PANs. The token persists even when the underlying card is reissued.

Key Takeaways

Tokenization is not encryption. Tokens are not reversible without the vault. This architectural property is what makes them effective at reducing PCI scope.
Three token types serve different purposes. EMVCo payment tokens flow through the entire network. Issuer tokens are bank-generated virtual PANs. Acquiring tokens are merchant-scoped storage substitutes. Don’t conflate them.
The TSP is the critical trust point. Visa (VTS) and Mastercard (MDES) operate the token vaults. The security of the entire scheme depends on vault integrity and access control.
Tokens are transparent to terminals. A POS terminal processes a token the same way it processes a PAN. The de-tokenization happens at the network/issuer level, not at the point of sale.
Tokenization and encryption work together. Use encryption for transport protection. Use tokenization for storage and scope reduction. They solve different problems.

Agentic AI for Software Development

Designing Multi-Agent Architectures That Actually Ship

Vincent Bevia | POS Architect & AI Systems Engineer | corebaseit.com

Abstract: Agentic AI is no longer a research curiosity — it is an emerging architectural pattern for software delivery. This document presents a practical blueprint for orchestrating multi-agent systems in real software development workflows: how to structure the agent hierarchy, what each specialist agent is responsible for, how they collaborate under a Super Agent orchestrator, and how to adapt the model for domain-specific contexts such as payment systems and POS architecture.

1. The Problem With Single-Agent AI

Most teams start with a single AI assistant: one model, one chat, one context window. It is a reasonable entry point. But as complexity grows, the single-agent model breaks down for the same reason that a single engineer cannot simultaneously own requirements, architecture, security, testing, and deployment at a production quality level.

The core limitation is not intelligence — it is specialization and scope management. A single agent juggling too many concerns produces outputs that are locally coherent but globally inconsistent: an API contract that does not match the implementation, a database schema that ignores the query patterns, or security controls that were described but never actually enforced.

Multi-agent architectures solve this by separating concerns structurally — the same way engineering organizations do.

2. The Super Agent Pattern

The Super Agent is the orchestrator at the top of the hierarchy. It does not write code directly. Its job is to understand the goal, decompose it into workstreams, delegate to the right specialist agents, resolve cross-agent conflicts, and synthesize a coherent final output.

2.1 What the Super Agent Is Responsible For

Goal comprehension: Parse the high-level product or engineering objective.
Task decomposition: Break the goal into discrete, delegatable workstreams.
Agent routing: Dispatch each workstream to the appropriate specialist.
Consistency checking: Verify that outputs across agents are aligned — contracts match implementations, tests cover requirements, security constraints are enforced.
Conflict resolution: When two agents produce incompatible outputs, adjudicate the correct path.
Human escalation: Identify decision points that require human judgment and surface them clearly.

2.2 Conceptual Role Mapping

A simple mental model that engineers find useful:

Super Agent → Tech Lead / Engineering Manager / Orchestrator
Sub-Agents → Domain Specialists
Validator Agents → Reviewers / QA / Security / Compliance
Human → Final Accountable Authority

3. The Specialist Agents

The following table summarizes the 12 core specialist agents, the layer they belong to, and their primary areas of responsibility. Each agent operates within a bounded context and reasons inside its own constraint domain — which is what makes the system effective.

Agent	Layer	Primary Responsibility
Requirements Agent	Product & Design	User stories, acceptance criteria, edge cases, non-functional requirements
Architecture Agent	Engineering	System boundaries, components, APIs, data flow, tradeoff analysis
API / Contract Agent	Engineering	OpenAPI specs, schemas, versioning, backward compatibility, error models
Frontend Agent	Engineering	UI components, state flows, accessibility, form handling, UX consistency
Backend Agent	Engineering	Business logic, service implementation, integrations, server-side validation
Database Agent	Engineering	Schema design, migrations, indexes, query patterns, data retention
Test Agent	Quality & Governance	Unit, integration, contract, regression, edge-case coverage
Security Agent	Quality & Governance	Auth/authz, secrets, OWASP risks, compliance, cryptography
Code Review Agent	Quality & Governance	Readability, maintainability, anti-patterns, naming, architectural drift
DevOps Agent	Delivery & Ops	CI/CD pipelines, environment configs, IaC, rollback plans, release checks
Observability Agent	Delivery & Ops	Logging, metrics, tracing, alerting, dashboards, operability
Documentation Agent	Product & Design	Technical docs, runbooks, READMEs, ADRs, onboarding, release notes

4. Agent Deep Dives

4.1 Requirements Agent

The Requirements Agent transforms vague feature requests into structured engineering artifacts. Given a prompt like “Build login with MFA,” it produces complete user stories with acceptance criteria, maps failure cases (wrong code, expired token, account lockout), defines timeout behavior and recovery flows, and surfaces non-functional requirements such as audit logging, rate limiting, and regulatory compliance constraints.

Output format: user stories, acceptance criteria tables, edge case catalogs, NFR specifications.

4.2 Architecture Agent

The Architecture Agent operates at the system level, not the implementation level. It defines component boundaries, service interfaces, data flow, and integration patterns. It reasons about tradeoffs — monolith versus microservice, event-driven versus synchronous, stateless versus stateful — and produces justifiable decisions rather than defaults.

Key questions it answers: Where does authentication live? What are the trust boundaries? Which components can fail independently? What is the retry and circuit-breaker strategy?

4.3 API / Contract Agent

Frontend and backend misalignment is one of the most common sources of integration bugs. The API Contract Agent eliminates this by owning the OpenAPI specification as the single source of truth. It enforces schema consistency, manages versioning strategy, defines backward compatibility rules, and produces error models that both producers and consumers can agree on before a single line of implementation code is written.

4.4 Frontend Agent

The Frontend Agent owns the user-facing layer end to end: component architecture, state management patterns, accessibility compliance (WCAG), form validation logic, client-side error handling, and UX consistency across flows. It works against the contract defined by the API Agent, which means its outputs are always integration-ready.

4.5 Backend Agent

The Backend Agent implements the business logic layer. It handles service implementation, integration patterns with external systems, queue and event handling, server-side validation, idempotency guarantees, and performance fundamentals such as connection pooling and query optimization. It operates against the same API contract as the Frontend Agent, eliminating a whole class of integration failures.

4.6 Database / Data Model Agent

Schema decisions made early in a project are often irreversible without expensive migrations. The Database Agent reasons about schema design, normalization tradeoffs, index strategy aligned with actual query patterns, data retention policies, and consistency constraints. It produces not just the schema but the migration scripts and rollback plans.

4.7 Test Agent

The Test Agent is arguably the most valuable agent in the hierarchy for long-term software quality. It reduces the gap between syntactically correct code and semantically correct behavior by generating unit tests, integration tests, contract tests aligned with the API specification, and regression scenarios derived from the requirements artifacts produced earlier in the pipeline.

Note: The Test Agent closes the loop between Requirements and Implementation — validating that what was built matches what was specified, not just that it compiles.

4.8 Security Agent

The Security Agent operates as a specialized reviewer with deep focus on authentication, authorization, secrets management, input validation, OWASP Top 10 risk coverage, compliance constraints, and cryptographic correctness. It does not just flag issues — it reasons about trust models and attack surfaces systematically, producing findings with remediation guidance.

For payment systems, this agent is non-negotiable: it enforces PCI DSS controls, validates cryptogram handling, and verifies that key material is never exposed in logs or error responses.

4.9 Code Review Agent

The Code Review Agent functions as a senior reviewer at scale. It assesses readability, maintainability, naming conventions, duplication, anti-patterns, and — critically — architectural drift: cases where the implementation deviates from the architecture decisions made upstream. It produces structured review comments with severity ratings and suggested remediation.

4.10 DevOps / CI-CD Agent

Deployment is where theoretical quality meets operational reality. The DevOps Agent manages build pipeline configuration, deployment workflow design, environment-specific configuration management, rollback procedures, and infrastructure-as-code correctness. It enforces deployment gates that prevent untested or non-compliant builds from reaching production.

4.11 Observability Agent

Systems that cannot be observed cannot be operated reliably. The Observability Agent defines the logging strategy, instrumentation approach, distributed tracing setup, metric collection, alerting thresholds, and dashboard design. It reasons about what needs to be visible at runtime to diagnose problems quickly and maintain SLA commitments.

4.12 Documentation Agent

Documentation written after the fact is almost always incomplete. The Documentation Agent produces technical documentation, operational runbooks, README files, onboarding guides, Architecture Decision Records (ADRs), and release notes — as a first-class output of the delivery process, not an afterthought. It works from the artifacts produced by other agents, ensuring documentation is consistent with the actual implementation.

5. Layered Hierarchy

Rather than a flat list of 12 agents all reporting directly to the Super Agent, a production architecture groups them into four functional layers. This mirrors how engineering organizations actually work — and it makes the orchestration logic simpler because the Super Agent can route at the layer level, not just the agent level.

Super Agent
├── Product & Design Layer
│ ├── Requirements Agent
│ ├── Frontend Agent
│ └── Documentation Agent
├── Engineering Layer
│ ├── Architecture Agent
│ ├── Backend Agent
│ ├── API / Contract Agent
│ └── Database Agent
├── Quality & Governance Layer
│ ├── Test Agent
│ ├── Security Agent
│ └── Code Review Agent
└── Delivery & Operations Layer
├── DevOps Agent
├── Observability Agent
└── Incident Response Agent

6. Example: End-to-End Orchestration Flow

Consider the following product requirement handed to the Super Agent:

“Build a subscription billing feature with admin dashboard and webhook support for real-time event notifications to merchant systems.”

Here is how the Super Agent orchestrates the delivery pipeline across specialized agents:

Step	Agent	Action
1	Requirements Agent	Defines user stories, acceptance criteria, edge cases, failure modes, audit requirements
2	Architecture Agent	Proposes service boundaries, event model, auth placement, trust boundaries
3	API Contract Agent	Defines billing and webhook OpenAPI contracts, error models, versioning rules
4	Backend Agent	Implements subscription logic, retry handling, idempotency, event emission
5	Database Agent	Designs plans, invoices, and events tables; defines indexes and migration scripts
6	Frontend Agent	Builds admin dashboard, billing UI components, subscription state machine
7	Security Agent	Validates auth, webhook signing (HMAC-SHA256), tenant isolation, secrets handling
8	Test Agent	Writes happy-path and failure-path tests, contract tests, regression scenarios
9	DevOps Agent	Updates CI/CD pipeline, injects environment secrets, validates deployment gates
10	Documentation Agent	Produces setup guide, webhook integration docs, runbook, and ADR
11	Super Agent (Verify)	Cross-checks contract alignment, test coverage, security enforcement, deploy safety

The Super Agent does not simply fire and forget. After each agent completes its workstream, the Super Agent runs a consistency pass: Are the API contracts consistent across Frontend and Backend? Do the tests actually cover the requirements? Have security constraints been enforced in the implementation, not just described in a spec? Is the deployment pipeline gated on the test and security outputs?

7. Domain-Specific Configuration: Payment Systems

Generic software-development agents are a useful starting point, but the real power of the multi-agent pattern emerges when agents are specialized for a specific domain. For payment systems and POS architecture, the agent configuration looks substantially different from a generic web application stack.

The constraint domains are more precise — EMV specifications, ISO 8583 message formats, PCI DSS requirements, L1/L2/L3 certification rules, and cryptographic key management standards are not optional concerns. An agent that reasons inside these constraints produces dramatically better outputs than a general-purpose agent given the same prompt.

Agent	Domain	Focus Area
EMV Agent	Payments Engineering	EMV transaction flows, cryptogram validation, chip card specs
ISO 8583 / Nexo Agent	Payments Engineering	Message formats, field mapping, authorization flows, protocol compliance
SoftPOS Mobile Agent	Payments Engineering	Android SoftPOS stack, tap-to-pay UX, L2/L3 SDK integration
Device Identity Agent	Payments Engineering	Android Keystore, attestation, key binding, ECDSA flows
PCI MPoC / CPoC Agent	Trust & Compliance	MPoC/CPoC controls, SCA compliance, audit readiness
Cryptography Agent	Trust & Compliance	DUKPT, 3DES/AES, key derivation, PIN block formats, HSM interaction
Certification Agent	Trust & Compliance	L1/L2/L3 certification readiness, terminal type mapping, test scripts
Merchant Onboarding Agent	Product & Business	Configuration flows, provisioning, terminal binding, fallback handling
Monitoring Agent	Delivery & Ops	Transaction telemetry, error rate tracking, alert thresholds, SLAs

Domain-specific agents do not just know more — they reason differently. A Cryptography Agent that understands DUKPT key derivation and PIN block formats will catch implementation errors that a general Security Agent would miss entirely.

8. Implementation Considerations

8.1 Agent Context Management

Each agent needs a well-scoped context: the artifacts it depends on as input, the artifacts it is expected to produce as output, and the constraints it must operate within. Agents given unbounded context become inconsistent; agents given no context produce generic outputs. The Super Agent’s most important function is context management — passing the right information to the right agent at the right time.

8.2 Feedback Loops

The architecture is not strictly sequential. Downstream agents will surface information that requires upstream agents to revise their outputs. The Test Agent may discover that the Requirements were underspecified. The Security Agent may find that the Architecture has a trust boundary flaw. The Super Agent needs a feedback routing mechanism to handle these cases without triggering cascading re-runs across the entire pipeline.

8.3 Human Checkpoints

The goal of multi-agent orchestration is not to remove humans from the loop — it is to move humans to the decisions that actually require human judgment. The Super Agent should surface clear, structured escalation points: design tradeoffs with no objectively correct answer, compliance decisions that carry regulatory risk, and deployment approvals before production releases.

8.4 Evaluation and Trust Calibration

Multi-agent systems amplify both good and bad outputs. An Architecture Agent that makes a flawed decision early in the pipeline will propagate that flaw to every downstream agent. Teams adopting this pattern should invest in per-agent evaluation frameworks: structured benchmarks that measure agent output quality against domain-specific criteria, not just syntactic plausibility.

9. Applied Example: The Software Code Developer Pipeline

While the full 12-agent hierarchy covers enterprise-scale delivery, many engineering teams need a leaner, faster configuration for day-to-day feature development. The Software Code Developer pipeline distills the Super Agent pattern down to five tightly coupled specialist agents — enough to take a requirement from specification to tested, documented code without unnecessary overhead.

9.1 The Five-Agent Code Pipeline

This configuration is optimized for a single engineer or a small team working on a well-scoped feature or module. The Super Agent coordinates a linear-but-iterative pipeline where each agent hands off structured artifacts to the next, and feedback loops are tight.

Agent	Input From	Responsibility
Requirements Agent	Human / Super Agent	Parses the feature request into user stories, acceptance criteria, edge cases, and explicit constraints. Produces the specification artifact all downstream agents depend on.
Coder Agent	Requirements Agent	Implements the feature: function signatures, business logic, error handling, and data structures. Writes against the specification, not against assumptions.
Refactor Agent	Coder Agent	Reviews the implementation for readability, maintainability, performance, naming, duplication, and structural quality. Produces a refactored version and a diff with rationale.
Test Agent	Coder + Requirements	Generates unit tests, edge-case tests, and regression scenarios aligned with the acceptance criteria. Validates that the refactored code passes all scenarios.
Documentation Agent	All agents	Produces inline code comments, function-level documentation, a README entry, and a brief ADR capturing the implementation decision and its rationale.

9.2 How the Super Agent Coordinates the Pipeline

The Super Agent’s role in this leaner configuration is primarily sequencing and quality gating. It does not just pass outputs forward — it validates that each agent’s output is fit for the next agent to consume. If the Requirements Agent produces an ambiguous specification, the Super Agent surfaces the ambiguity before the Coder Agent starts — not after.

After Requirements: Validates that all acceptance criteria are testable and all edge cases are explicitly named.
After Coder: Checks that the implementation addresses every requirement line item before passing to Refactor.
After Refactor: Confirms the refactored code has not deviated from the original acceptance criteria.
After Test: Verifies test coverage against the requirements specification — not just code line coverage.
After Documentation: Ensures the documented behavior matches the actual implementation.

9.3 A Concrete Walk-Through

Consider this feature request passed to the Super Agent:

“Implement a token refresh mechanism for the SoftPOS authentication flow. Handle expired tokens gracefully, retry once on 401, and log all refresh events for audit.”

Requirements Agent: Produces: user story (“As a SoftPOS device, I need to refresh my auth token automatically…”), acceptance criteria (token refreshed before expiry, 401 triggers exactly one retry, audit log written on every refresh attempt, refresh failure surfaces a structured error to the caller), edge cases (refresh token itself expired, network timeout during refresh, concurrent requests during refresh window), and NFRs (refresh must complete within 2 seconds, audit log must be tamper-evident).

Coder Agent: Implements: TokenRefreshInterceptor class, retry logic gated on 401 response code, exponential backoff for the single retry, structured AuditLogger.logRefresh() call on every attempt, and a RefreshFailureException with error code and context. Writes against the requirements artifact — not against a generic “token refresh” pattern.

Refactor Agent: Reviews and improves: extracts the retry logic into a reusable RetryPolicy interface, renames ambiguous variables (token vs accessToken vs jwt), removes a duplicated null-check, adds a circuit-breaker flag to prevent retry storms, and flags one potential race condition in the concurrent-request edge case for the Coder Agent to resolve.

Test Agent: Generates: happy-path test (token refreshed successfully, audit log entry written), 401-retry test (first request fails, refresh succeeds, original request retried once), retry-exhaustion test (both attempts fail, RefreshFailureException thrown with correct code), concurrent-request test (two simultaneous calls do not trigger two independent refresh flows), and audit log integrity test (log entry contains timestamp, device ID, outcome, and correlation ID).

Documentation Agent: Produces: inline Javadoc on TokenRefreshInterceptor and all public methods, a README section titled “Authentication & Token Refresh” with sequence diagram reference, and an ADR documenting why single-retry-with-circuit-breaker was chosen over exponential backoff for compliance with the SoftPOS session timeout requirements.

9.4 Why Five Agents Beat One

A single AI assistant given the same token refresh prompt will produce working code — most of the time. What it will rarely produce unprompted: a complete edge case catalog, a refactored version with extracted interfaces, tests that cover the concurrent-request race condition, and an ADR that explains why the implementation made the choices it did.

The five-agent pipeline produces all of these as structured, auditable artifacts — not as prose in a chat window. The difference is not just quality; it is traceability. Each artifact is linked to a specific agent’s domain, which means failures are diagnosable and improvements are targeted.

The five-agent pipeline is not slower than a single-agent approach — it is more parallel. The Super Agent can run the Coder and Requirements agents concurrently on different subtasks, then merge outputs before handing off to Refactor and Test. Wall-clock time is often comparable; output quality is not.

10. Key Principles

Specialization over generalization: An agent with a narrow, well-defined domain produces higher-quality outputs than a single general agent asked to do everything.
Contracts as coordination: API specifications, schema definitions, and requirements artifacts are not just deliverables — they are the coordination mechanism between agents.
Validation is non-negotiable: Every specialist agent needs a corresponding validation step. The Test Agent validates the Backend Agent. The Security Agent validates the Architecture Agent.
Human authority is structural: The human is not an optional escalation path — they are the final accountable authority built into the architecture.
Domain specificity multiplies value: Generic agent hierarchies are useful; domain-specific agent hierarchies are transformative. Configure agents for your constraint domain.

11. Conclusion

Multi-agent architectures represent the next practical step in AI-assisted software development. The single-agent model is appropriate for bounded tasks. For complex, multi-stakeholder software delivery — where requirements, architecture, implementation, testing, security, and deployment must all be internally consistent — a coordinated hierarchy of specialist agents orchestrated by a capable Super Agent is a fundamentally more robust approach.

The pattern is not theoretical. The components — requirements generation, architecture reasoning, contract definition, code review, security analysis, test synthesis — are already being performed by AI models today. What the Super Agent pattern adds is the coordination layer: the planner, the validator, and the synthesizer that makes the specialist outputs cohere into something shippable.

The engineers who learn to design these systems — not just to use individual AI tools, but to architect the agent hierarchies, define the feedback loops, and calibrate the human checkpoints — will have a significant advantage in the decade ahead.

Vincent Bevia | POS Architect & AI Systems Engineer | corebaseit.com

Corebaseit_posts_in_reviews on Corebaseit — POS · EMV · Payments · AI

I Spent Years on Adaptive Filters. I Was Already Training Neural Networks.

LMS Is Not a Metaphor for Training — It Is the Algorithm

The Engineering Trade-Offs Are the Same Trade-Offs

Non-Stationarity Was Always the Real Problem — and Still Is

The Bigger Picture

References

Further reading

Why Parents Still Matter in the AI Era

The Question Is Not Whether AI Can Help

The Real Risk: Slow Substitution

What the Research Actually Emphasizes

What Responsibility Looks Like in Practice

Formation Is Still the Work of People

Reference

Further reading

Multi-Agent Systems Scale Vertically. They Need to Scale Horizontally.

What Vertical Scaling Actually Means

The Statefulness Illusion

The Horizontal Scaling Problem

What the Field Has Built as Workarounds

What Is Actually Missing

Why the Industry Has Not Solved It

The Architectural Opportunity

References

Swarm Intelligence: The Opposite Architectural Bet

What Is Swarm Intelligence?

From Biology to Algorithms

The Two Dominant Algorithms

Ant Colony Optimization (ACO)

Particle Swarm Optimization (PSO)

A Minimal PSO Example

Swarm vs. Orchestrator: The Architectural Trade-Off

The Hybrid: Where Both Patterns Meet

What I Took Away from All of This

References

Super Agents and Multi-Agent Communication: Architecture That Actually Scales

What Is a Super Agent?

Do Agents Actually Talk to Each Other?

Communication Mechanisms

Coordination Patterns

A Minimal In-Process Pattern

Why This Pattern Scales

The Super Agent as Orchestrator

Single Source of Truth: Non-Negotiable

The Bigger Picture

References

Data Quality and Accessibility — The Foundation You Can't Skip

Data Quality and Accessibility — The Foundation You Can’t Skip

Completeness

Consistency

Relevance

Availability

Cost

Format

ML Lifecycle Stages — The Cycle That Never Stops

ML Lifecycle Stages — The Cycle That Never Stops

1. Data Ingestion and Preparation

2. Model Training

3. Model Deployment

4. Model Management

The Cycle Continues

References

The AI Hierarchy — From Broad to Specific

The AI Hierarchy — From Broad to Specific

Artificial Intelligence (AI)

Machine Learning (ML)

Deep Learning

Generative AI

Natural Language Processing (NLP)

The Generative AI Landscape — A Layered View

The Generative AI Landscape — A Layered View

Infrastructure

Models

Platform

Agents

Applications

The Missing Piece: Scaffolding

Reasoning Models and Deep Reasoning in LLMs: Chain-of-Thought, Tree of Thoughts, and Test-Time Compute

Chain-of-Thought Prompting: Forcing the Model to Show Its Work