Forem: Promise

Toxic Relationships 💔: When Your Agents Hallucinate

Promise — Fri, 13 Feb 2026 11:25:39 +0000

Love is blind, but in production, blind trust is a fatal architectural flaw.

This Valentine’s Day, while others talk about chemistry, let’s talk about state divergence. The most toxic relationship in your stack is the one between an unmoderated Lead Agent and a specialised Worker. Without strict validation, your agents will start finishing each other's sentences in the worst way possible: by hallucinating context that doesn't exist.

Reliability in autonomous systems isn't about better prompting. It is about better boundaries. When you allow an agent to update your global state without a verification layer, you are essentially allowing a non-deterministic process to rewrite your source of truth.

The Actor-Critic Architecture

Instead of a linear chain of command, we deploy an Actor-Critic pattern. This separates the creative process of problem-solving from the rigid process of validation. The Actor proposes a solution, but the Critic, governed by a different set of constraints and tools, must sign off on the work before it is committed to the state.

The diagram below illustrates this relationship. Notice that the human is not a bottleneck for every task, but sits behind a high-integrity gate for critical actions.

graph TD
    A[User Request] --> B{Lead Orchestrator}
    B --> C[Actor Agent: Generation]
    C --> D[Proposed Action/Code]
    D --> E{Critic Agent: Validation}
    E -- Rejected: Hallucination Detected --> C
    E -- Approved: Schema Validated --> F[Human-in-the-Loop Gate]
    F -- Approved --> G[Production Execution]
    F -- Denied --> B
    G --> H[Update Global State]

Breaking the Feedback Loop

The danger of agentic relationships is the echo chamber effect. If an Actor Agent makes a mistake and the Orchestrator accepts it as fact, every subsequent step in the graph is built on a lie. We break this by ensuring the Critic has access to an independent source of truth, such as a read-only database or a static documentation repository, which the Actor cannot influence.

By the time the process reaches a Human-in-the-Loop gate, the "relationship" between the agents has already filtered out the noise. The human isn't there to fix basic logic errors. They are there to provide high-level strategic approval.

The Strategic Benefit

Moving from blind execution to Actor-Critic orchestration changes the ROI of your AI initiatives. You spend less time debugging erratic behaviour and more time scaling the system.

Reduced Token Waste: Catching errors early in the graph prevents expensive, long-running loops based on false premises.
Auditability: Every disagreement between the Actor and Critic is logged, providing a clear map of where your prompts or tools need refinement.
Governance: You can swap out the Actor for a cheaper model while keeping a high-frontier model as the Critic to maintain quality control.

Stop falling in love with your first prototype. Build an orchestration layer that challenges its own assumptions.

Would you like me to design a specific Critic schema for your most frequent agent failure modes?

Agentic Amnesia: The State Management Crisis

Promise — Sat, 07 Feb 2026 03:08:26 +0000

The most significant bottleneck in 2026 enterprise AI isn't model intelligence. It is memory.

We see it weekly at Prodevel. A firm deploys a sophisticated multi-agent system to handle supply chain logistics or legal discovery. For the first three steps, the system is brilliant. By step four, the agents begin to wander. By step six, they have forgotten the original constraint entirely. This is agentic amnesia: the catastrophic loss of context that occurs when an autonomous system fails to maintain a persistent, coherent state.

In the early days of 2024, we relied on long context windows to solve this. We simply stuffed the entire conversation history into the prompt. But in a production environment where agents interact with dozens of tools and generate thousands of tokens, "context stuffing" is both expensive and noisy. It leads to the lost-in-the-middle phenomenon, where the model ignores the very instructions that matter most.

The Architecture of Remembrance

To solve this, Prodevel has moved away from stateless chains. We treat agentic workflows as long-running processes that require a dedicated state backend. If your agent doesn't have a "checkpoint" system, it isn't an enterprise tool. It is a toy.

We utilize a state-first design pattern. Instead of passing a growing string of text between agents, we pass a pointer to a structured state object stored in a persistent layer like Redis or Postgres.

Check-pointing: Every time an agent calls a tool or makes a decision, the state is saved. If the execution environment crashes, the agent resumes from the last known good state rather than restarting the entire reasoning loop.
Thread Scoping: We decouple the short-term working memory (the current task) from the long-term archival memory (the project history).
State Summarisation: As the state grows, a background "Summariser Agent" compresses older interactions into high-signal metadata. This keeps the active context window lean and focused.

Technical Implementation: The Checkpointer Pattern

Here is how we implement persistent state management in a 2026 agentic graph using a TypeScript-based orchestration layer. This ensures that the agent retains its "identity" and progress across asynchronous tool calls.

import { StateGraph } from "@langchain/langgraph";
import { RedisSaver } from "@langchain/langgraph-checkpoint-redis";

// Define the schema for our persistent state
const StateSchema = {
  plan: { value: (x, y) => y, default: () => [] },
  completed_steps: { value: (x, y) => x.concat(y), default: () => [] },
  current_error_count: { value: (x, y) => y, default: () => 0 },
};

// Initialize the Redis-based checkpointer for 2026 production loads
const checkpointer = new RedisSaver({ 
  uri: process.env.REDIS_URL || "redis://localhost:6379" 
});

// Build the graph with a 'Thread ID' for persistence
const workflow = new StateGraph({ channels: StateSchema })
  .addNode("researcher", researchNode)
  .addNode("writer", writingNode)
  .addEdge("researcher", "writer");

// The 'thread_id' is the secret to curing amnesia
const app = workflow.compile({ checkpointer });

const config = { configurable: { thread_id: "project_finance_audit_001" } };
await app.invoke({ plan: ["Analyze Q4 data", "Check compliance"] }, config);

The Strategic Moat

Founders often ask why they should invest in custom orchestration rather than using a standard chat interface. The answer is reliability. A stateless agent is a liability because its failure mode is silent and unpredictable.

A state-managed system provides a full audit trail. You can see exactly where the logic diverged. You can rewind the state, fix the underlying tool or prompt, and re-run the execution from the point of failure. This isn't just better engineering. It is the only way to build a moat around your AI operations in 2026.

If your agents are currently wandering in circles, you don't have a model problem. You have a state problem.

Would you like me to review your current orchestration logic to identify where your state is leaking?

5 skills you need to develop as a recent Computer Science Graduate

Promise — Fri, 06 Feb 2026 16:23:09 +0000

The Post-Syntax Era: 5 Skills for the 2026 CS Graduate

Congratulations. You have graduated into the most volatile labour market in the history of computing.

In 2026, the industry has undergone a fundamental decoupling. Writing syntax is no longer the moat for a software engineer. LLMs and autonomous agents have commoditised boilerplate, unit testing, and even complex refactoring. If you enter the workforce expecting to be a coder, you are already obsolete.

At Prodevel, we look for systems architects in training. These are graduates who understand that software is now a collaborative dance between human intent and agentic execution. Here are the five non-negotiable skills you need to survive and thrive in 2026.

1. Agentic Orchestration and Graph Logic

By now, prompt engineering is a relic of 2024. Today, we build agentic workflows. You need to move beyond single-turn chats and learn to design multi-agent systems where specialised models, such as Architects, Coders, and Reviewers, collaborate within a state-controlled environment.

The Technical Shift: Mastering frameworks like LangGraph or PydanticAI to manage cycles and state.
Why it matters: You aren't writing the code. You are writing the logic that governs the agents writing the code.

2. Context Engineering and RAG 2.0

In 2026, the bottleneck isn't the model's parameters. It is the data you feed it. Retrieval-Augmented Generation (RAG) has evolved from simple vector searches into complex agentic RAG pipelines that utilise knowledge graphs and hybrid search.

The Skill: Understanding how to structure unstructured data, including PDFs, Slack logs, and Notion, into a format an LLM can actually reason over without hallucinating on outdated context.
Prodevel Insight: If you can't manage a vector database like Pinecone or Weaviate and optimise a retrieval pipeline, you are effectively flying blind.

3. Security-by-Design and Agentic Guardrails

With autonomous agents operating at scale, the attack surface has exploded. We have seen prompt injection evolve into agent hijacking, where malicious actors attempt to take control of an agent’s tool-calling capabilities.

The Requirement: You must understand the OWASP Top 10 for LLMs.
Implementation: Learning to deploy strict Human-in-the-Loop (HITL) gates and sandbox environments for agent-executed code. In 2026, a developer who ships an agent without execution guardrails is a liability.

4. Mathematical Foundations (The Deep T-Shape)

While tools change every six months, the math doesn't. To debug a model that is behaving erratically, you need to understand what is happening under the bonnet.

The Core: Linear algebra, probability, and transformer architecture.
The Value: When an agent gets stuck in a reasoning loop, a junior dev tries a different prompt. A Prodevel engineer analyses the attention mechanism or temperature settings to fix the root cause.

5. Multi-Cloud and Edge Deployment

The cloud is no longer just AWS or Azure. In 2026, we are deploying smaller, domain-specific models (SLMs) to the edge. This includes mobile devices, IoT, and local servers to reduce latency and cost.

The Toolset: Kubernetes, Docker, and WebAssembly (Wasm) for running high-performance AI logic in the browser or at the edge.
Strategic Advantage: Companies are desperate for engineers who can balance the intelligence-to-cost ratio by deciding when to use a frontier model versus a local, fine-tuned Llama-4 variant.

Tool Definition Logic

In 2026, we spend more time defining tools than functions. Here is how a Prodevel engineer defines a type-safe tool for an agent using TypeScript:

import { z } from "zod";

export const DatabaseQueryTool = {
  name: "query_production_db",
  description: "Executes read-only SQL queries. Requires Human-in-the-loop for DELETE/UPDATE.",
  schema: z.object({
    query: z.string().describe("The SQL query to execute"),
    limit: z.number().default(100),
  }),
  execute: async ({ query, limit }, context) => {
    const forbidden = ["DELETE", "DROP", "UPDATE", "TRUNCATE"];
    if (forbidden.some(word => query.toUpperCase().includes(word))) {
      throw new Error("Unauthorized: Destructive queries require manual sign-off via HITL-Gate.");
    }
    return await db.readOnlyPool.query(query, { limit });
  }
};

The Bottom Line

The 2026 Computer Science degree is a ticket to the stadium, not a seat in the VIP box. To stay relevant, you must pivot from being a builder of software to an orchestrator of intelligence.

So .. I coded in Python

Promise — Wed, 10 Jan 2024 17:14:27 +0000

I have been using PHP for as long as I can remember. However, recently, I decided to pick up another programming language. As an API developer, one of the my biggest searches when building scalable APIs is how much requests can the api take before giving up.

I initially attempted to learn Scala but that syntax looked like hieroglyphics to me and the set up was just way to cumbersome. I also tried working on other (backend) languages like Go and even NodeJS. By the way, Scala is really fast. No seriously!

Finally, I decided to give Python a real go (no pun intended). It was tedious at first, you had to indent properly. A case of a missing line can cost you sleepless debug minutes.

Then you have random variables like ***kwargs* and the rest. Sigh.

After breaking through the initial barriers however, I started to appreciate the language some more. I learnt about list comprehension, the difference between (lists) and dicts, strict typings and my personal favourite; Protocols.
Photo by Markus Spiske: https://www.pexels.com/photo/black-laptop-computer-turned-on-showing-computer-codes-177598/

Also, great thanks to the team at Django for an awesome framework, definitely made things a lot smoother. I have now completed my first project that I will be shipping into production this week. What a journey it has been. Sure it could have been easier with PHP, but back to the latency issue. My code looks more succint and chops through tasks at an alarming rate (this is a good thing).

So if you are looking for a part time language, pick Python. I mean, look at this beauty:

        if res.ok:
            response_body = json.loads(res.content)
            web_ids = {item['reference']: item['id'] for item in response_body['data']}
            cases = [When(reference=key, then=value) for key, value in web_ids.items()]
            Place.objects.filter(reference__in=web_ids.keys()).update(webId=Case(*cases))

Here is an AI generated joke for you:

Why do Python programmers prefer dark mode?

Because light attracts bugs!

DB Search and Replace. The automated kind

Promise — Wed, 03 Aug 2022 21:28:00 +0000

Imagine you had to make a change in your database records. You have been assigned the task of updating the affected records. There is only one problem: you do not know which tables or how many records are affected. What do you do?

That was an actual scenario that occurred sometime this week. Except, it wasn't some nefarious line of code. It was time to fix those horrible class names used in Laravel relationships. You know what I am talking about: the App\Models\User kind littered across the database.

This tutorial will show you how to run a search and replace using Laravel's built-in migration and DB classes. It should help you avoid manually running a search and replace or using an external tool.

Create a migration

Generate a migration file using the artisan console.
php artisan make:migration search_replace_relationships

Search and replace logic

Remember, you do not know what tables are affected and what column so, you cannot run: DB::update(). Instead, we have to do the following:
Get a list of items to search for and replace
Get a list of tables
Get a list of columns in each table
Run a nested for loop
If you are updating multiple items, you will need an additional loop for each item you wish to replace.

Get a list of changes

In this case, we are replacing relationship morphs. You can create a morph map as described here. For example, our morph map looks like this:

Relation::morphMap([
            'user' => User::class,
            'post' => Post::class,
        ]);

We can then retrieve the morph map using:

$morphMap = \Illuminate\Database\Eloquent\Relations\Relation::morphMap();

Get a list of all tables

I could not find native support for retrieving table names in Laravel. Alternatively, you can run this query to retrieve a list of database tables.
$tables = \Illuminate\Support\Facades\DB::select('SHOW TABLES');
Inspired by

Get a list of columns for each table

Here is our first loop.

foreach ($tables as $table) {
            $tableName = $table->{sprintf('Tables_in_%s',
                \Illuminate\Support\Facades\DB::connection()->getDatabaseName())};
            $columns   = Schema::getColumnListing($tableName);

The result of the first query to retrieve the table names returns an array of objects. Each object key is Tables_in_dbname. Using the correct key syntax, get to the value which holds the actual table name.
Next, we use the Schema class to get the columns of the table name while still in the loop.

Run a nested loop

Here comes our first nested loop. For each table, loop through each column to find the text that we want to change and perform the replacement:

foreach ($columns as $column) {
                $columnType = Schema::getColumnType($tableName, $column);
                if ($columnType === 'string') {

We use the Schema::getColumnType function to get the type of the column. That is because in this case, we are replacing the morph types so we know that the field for morph types is usually a string. If this is different in your setup (very unlikely) you can skip this entirely.

Run the replace

Finally, we run the search and replace logic.

\Illuminate\Support\Facades\DB::table($tableName)->where($column, $value)->update([$column => $key]);

Retrieve an instance of the table, then search for the value in each column and replace it using the update function.
The SQL equivalent is:
UPDATE FROM $tableName where $column = $value SET $column = $key the $key in this case being the user for the first item in our morph map and $value being the class name in this case App\Models\User.

Please note that the update method does not fire any eloquent events, which is the behaviour we want since we are running a migration.

Bring it all together.

In your migration up function, you should end up with the following:

$tables   = \Illuminate\Support\Facades\DB::select('SHOW TABLES');
        $morphMap = \Illuminate\Database\Eloquent\Relations\Relation::morphMap();
        foreach ($tables as $table) {
            $tableName = $table->{sprintf('Tables_in_%s',
                \Illuminate\Support\Facades\DB::connection()->getDatabaseName())};
            $columns   = Schema::getColumnListing($tableName);
            foreach ($columns as $column) {
                $columnType = Schema::getColumnType($tableName, $column);
                if ($columnType === 'string') {
                    foreach ($morphMap as $key => $value) {
                        \Illuminate\Support\Facades\DB::table($tableName)->where($column, $value)->update([$column => $key]);
                    }
                }
            }
        }

I think migrations are one of the most powerful features offered by any framework. Once you have mastered how to use migrations, you can resolve minor to large database infractions without ever logging into your production database.

Have you found this useful, comment below.

Photo by Anete Lusina:

Lazy load config on Laravel

Promise — Sat, 04 Jun 2022 18:09:21 +0000

It is common knowledge that configuration on Laravel applications are one of the very first things to load. If it is not, well, check out the application lifecycle here. As part of the autoconfiguration of Laravel, everything in the config folder is considered an application configuration and loads pretty much as soon as the application is booted.

Why is this important? We will get to that in a second. First how can we achieve this.

The first step is to create a custom service provider. If you are not sure what these are, here is the doc for it.

I created one called CustomConfigServiceProvider. You can place this in the Providers directory.

Next create a new custom folder for your custom configuration files. Remember, everything in config is autoloaded. I created a folder called custom-config

In the boot section of the provider, add the following piece of code.

parent::boot();
$this->mergeConfigFrom(__DIR__.'/../../../custom-config/settings.php', 'settings');

You are probably thinking, what is happening here? Let me break it down. Here is how your file should look:

<?php

namespace App\Providers\Custom;

use Illuminate\Support\ServiceProvider;

class CustomConfigServiceProvider extends ServiceProvider
{
    public function boot()
    {
        parent::boot();
        $this->mergeConfigFrom(__DIR__.'/../../../custom-config/settings.php', 'settings');
    }

    public function register()
    {
        parent::register();
    }
}

First since every provider is extending the base ServiceProvider class from the framework, we are calling parent::boot() to ensure the code block runs first.
Then we are merging our new configuration into the configuration set that was already loaded previously. In this case, we have a custom configuration file called settings.php

Now you have everything set up for your lazy loaded configuration.

There is just one last step to complete. We need to register our service provider. In your config/app.php file, add your new provider in the providers array.

Viola, you now have lazy loaded configuration.

For the use cases, there are numerous, for instance, if you have a configuration that relies on a third-party application to have been loaded previously. More on this later.

Check out some cool features of Laravel 9. Are you using lazy loaded configurations? Let me know in the comments.

Laravel 9 Best Features

Promise — Tue, 08 Feb 2022 23:23:28 +0000

So I went to read up on some Laravel documentation regarding Homestead because you know, Docker on Mac, arghhh, well that is a story for another day.

Anyway, Laravel 9 is out and one of the features that stood out for me was the support for generic types. If you do not know what these are, there is a great article by Ondřej Mirtes regarding them here.

What does this have to do with Laravel? Well, I am coming to that in a minute. One of my favourite features in Laravel is Eloquent, more specifically, Eloquent relationships. But there has always been something missing, whenever you get the collection instance, the IDE does not know what types are inside the collection.

Consider the code below, I have been using generic type hinting for a while in my code, more in a documentation capacity.

* @property Collection<Notification> $notifications

If I call the notifications property, I correctly get that it is an instance of Collection but what I don't get is that the contents are instances of Notification.

So $notifications->first() will simply be an object with no type. I will need to type hint the resulting object if I wanted to get autocomplete.

With this change in Laravel 9, the extra comment type hint is now unnecessary. I can simply type-hint the collection with a generic like above and get the correct instance. This will help clean up a lot of unnecessary comments in the code.

Anyway, if that does not get you excited, you can check out some of the other features here.