Coder Legion - Recent posts tagged automation

Tricked Claude to Design the system, Not to Code (part 1)

Fri, 30 Oct 2026 08:58:59 +0000

I wanted to explore automation for a few days, and I came across
Minicor, a company working on the problem of automating legacy
software. The problem is simple, and I'm still figuring out whether it
is worth solving at this level. But I learned a lot while building this
project.

Let's start.

Folks who want to see and demonstration
github
live link
watch the demo

Understanding the pain

I can relate to this problem from my experience working with Tally back
in 2018. You simply couldn't automate many scenarios easily. Tally was
licensed software, and in practice, some people used pirated versions.
The software generally had to be installed on a particular system, and
there often wasn't an API available for the workflow you wanted to
automate. Add network restrictions and other environment-specific
limitations, and the problem becomes even harder.

There may be more integration options available today, but the broader
question remains:

How do we reduce manual work and make these workflows faster when the
software wasn't designed to be automated?

That's where Minicor caught my attention.

How I understand Minicor

As far as I understand it, Minicor breaks the problem into a few steps:

A business requests an automation for a particular scenario.
Minicor understands the requirements and how a human performs that
task.
It creates and tests a workflow for that scenario.
Once the business approves the workflow, Minicor exposes an API.
The business can call that API whenever it needs the task performed.

I took this idea and started building SmartPay: an automation that
creates an invoice on every API hit.

But how would we design this for more users and more legacy systems
while keeping the system reliable?

While working through distributed-system design, I realised something
important: before jumping into requirements and fancy features, we
should first track the events and understand how a payload moves from
one service to another.

Here is the flow I want to design:

Business demonstrates a scenario → Engine proposes a workflow →
Business approves it → API is exposed → Business calls the API →
Workflow succeeds, fails, or ends in an uncertain state.

That last part is important. What happens if the system fails and we
don't know whether the invoice was created?

Functional requirements

Let's derive the requirements from the flow above.

Record scenarios and workflows. We need to capture the business
process that the automation is supposed to perform.
Store workflow definitions and parameter mappings. Each workflow
should define the inputs it needs and how those inputs map to the
actions being performed.
Publish workflows for business review. The business should be
able to review the workflow name, parameters, outputs, and commit
step before approving it.
Expose an API for each published workflow. Every API request
must be validated against that workflow's rules.
Provide a monitoring dashboard. Business users should be able to
inspect runs and take action when something needs attention.

Out of scope for now: AI-based repair when a screen changes, editing
workflow steps through the UI, tenant and user management, and billing
for the automation engine itself.

Non-functional requirements

Every non-functional requirement should support one or more of the
functional requirements above.

Before defining them, let's look at two important failure scenarios.

1. Graceful handling of saves

We need to understand what happens when a workflow is interrupted while
saving an invoice.

2. Uncertain outcomes

Consider two scenarios:

The business's system stops before the invoice is saved.
The business's system stops after the invoice is saved, but
before our engine records the success.

In the second scenario, the invoice exists, but our system may not know
that. If we retry blindly, we could create a duplicate invoice and
potentially charge a customer twice.

This leads to an important requirement: we must prevent duplicate
invoice creation, even when the outcome of an execution is uncertain.

We need idempotency for each invoice operation. We also need to
distinguish a confirmed failure from an uncertain outcome. An uncertain
run should be reconciled before another attempt is allowed to create an
invoice.

In other words, we shouldn't blindly retry an API request just because
we didn't receive a successful response. The same request needs a stable
idempotency key, and the execution system must check whether the
intended effect already happened.

We also need to store the workflow definitions, parameters, mappings,
and rules in a structured format, such as JSON, so every API request can
be validated against the workflow it invokes.

What about response time?

How fast should an API request be?

Here's the catch: we can optimise everything on our side, but what if
the target application itself is slow?

We might be able to acknowledge a request in under 500 ms, but that does
not mean the invoice will be created in 500 ms. The legacy billing
application may take much longer to complete the operation.

So we need to distinguish between API response time and workflow
completion time.

This leads to another question: what happens when we receive 50,000
requests?

That's what I spent a good few hours discussing with Claude. Before
getting into the cost estimates, I found it useful to understand a few
basic concepts.

Cost estimation

Before going deeper, here are three questions that help us estimate
capacity and cost.

Concept	Question	What it helps estimate
Rate	How quickly do requests arrive?	API requests per second, database writes per second, and queue throughput
Concurrency	How many operations are in progress at once?	Worker slots, connections, and memory
Size	How much data does each operation produce?	Storage, bandwidth, and cost

A useful mental model is:

Rate = number of requests ÷ time window
Concurrency ≈ rate × average processing time
Storage = number of records × average record size

We also need to ask one more question: what is the limiting resource,
and where does that limit live?

Let's assume 50,000 requests

Suppose we need to process 50,000 invoices in four hours.

Four hours is 14,400 seconds, so the average arrival rate is:

50,000 ÷ 14,400 ≈ 3.5 requests per second

Now suppose the legacy application takes around 30 seconds to create
one invoice.

Using Little's Law:

Concurrency ≈ 3.5 requests/second × 30 seconds ≈ 104 concurrent runs

At first, that doesn't sound too bad. Around 104 runs in progress seems
manageable from an infrastructure perspective.

But there is another constraint.

The legacy system is the bottleneck

Let's assume each business has one legacy application instance, and that
instance can create only one invoice at a time.

If one business needs to process 500 invoices, and each invoice takes 30
seconds:

500 × 30 seconds = 15,000 seconds = 4 hours and 10 minutes

That already exceeds our four-hour target.

Adding more API servers or workers won't solve this problem. If the
target application can process only one invoice at a time, the
automation engine cannot make that individual instance process invoices
faster simply by adding infrastructure.

The real capacity limit is the concurrency supported by each business's
legacy application. Increasing it may require additional sessions,
application instances, or licences, depending on what the software and
the business environment support.

So the important question isn't simply, "How do we handle 50,000
requests?"

It is: How many requests can arrive, how long does each workflow take,
and how many workflows can each target system safely execute at once?

Do we need Kafka or SQS?

For this assumed workload, we don't necessarily need Kafka or SQS from
day one.

We could start with PostgreSQL as the durable job queue, keeping the
execution record and queue state in the same database. That reduces the
number of systems we need to operate and helps keep the execution state
consistent with the queued work.

Core entities

Before implementing the system, I want to identify the core entities and
how they relate to each other.

Entity	Meaning	Example
Tenant	The business using our platform	Sharma Traders
Client App	The application calling our API	A script or Postman during development
Target App	The software product being automated	Tally
Target Instance	A particular installation or instance of that software	Sharma Traders' Tally installation
Agent	The automation worker that performs the task	A worker operating the target application
Workflow	The task the business wants to automate	`create-invoice`
Demonstration	The recorded example from which a workflow version was created	A recording of a person creating an invoice
Run	One invocation of a workflow, including its input and outcome	A request to create a particular invoice

At a high level, the relationships look like this:

Tenant
├── Target Instances ──> Target App
│   └── Agents
├── Client Apps
│   └── Runs ──> Target Instance
└── Workflows
    └── Demonstrations

Workflow ──> Runs

Where I'll pause for now

I wanted to keep this part focused on understanding the problem, tracing
a request through the system, and identifying the first set of design
constraints. There is still a lot to explore, especially around queue
implementation, failure recovery, and cost estimation.

I'll leave the deeper implementation details for the next part. For now,
the main lesson is simple: before scaling the automation engine,
understand the workflow, track the request end to end, and identify the
system that actually limits throughput.

How to give your AI Agent access to a Real iPhone

Thu, 29 Oct 2026 16:16:58 +0000

For a long time, mobile automation has been much easier to demonstrate on Android than on iOS. Android has ADB, emulators, and relatively accessible automation tooling. iOS has a different set of constraints, especially when you want to interact with a physical device and the apps installed on it.

But what if you could give an AI agent access to your actual iPhone, describe a task in plain English, and let it carry out the steps?

That's what we've been working on at Mobilerun.

Why iPhone automation is difficult

AI agents have become good at reasoning, writing code, and interacting with websites. Mobile apps introduce another layer of complexity.

An agent might need to navigate multiple screens, locate a button, enter information, handle a dialog, and verify that an action actually succeeded.

On iOS, automation is harder because of Apple’s restrictions, connection issues, and the setup needed to control a real iPhone.

Traditional automation often relies on predefined scripts or app-specific integrations. These work well when the workflow is known in advance, but they can be restrictive when you want an agent to handle different tasks dynamically.

An AI agent that can interact with a phone's UI has another option: it can observe the screen, decide what to do next, and perform the necessary interactions.

Instead of building a separate integration for every task, you can describe the outcome you want and let the agent work through the interface.

From a prompt to a real iPhone

With Mobilerun Cloud, you can connect your own iPhone through a Mac or Linux or Linux and make it available for automation.

The workflow is straightforward:

Connect your iPhone to your Mac or Linux or Linux using a USB cable.
Follow the setup instructions to connect it to Mobilerun Cloud.
Open your connected device and give your agent a task.
Watch the agent interact with the phone.

Once connected, you can issue a command and let the agent navigate the UI, tap controls, type text, and move between screens.

You don't need to build a dedicated automation script for every prompt.

Setup takes under two minutes in the supported configuration. You'll need an iPhone running iOS 27 or later and a Mac or Linux.

Follow the iPhone connection guide to get started.

What can you automate?

The interesting part isn't simply getting an AI to tap a button. It's being able to describe a task and have the agent work through the steps on a real device.

Here are a few examples worth exploring.

1. Messaging workflows

You could ask an agent to open Messages, find a conversation, and draft or send a message.

For example:

Open Messages, find my conversation with Maa, and send her a message saying I'll call her this evening.

This is a simple example, but it demonstrates the core idea: the task is described in natural language, and the agent translates it into UI interactions.

Always review messages and confirm the intended recipient before allowing an agent to send anything important.

2. Navigating apps

An agent could be asked to open an app, find a particular section, search for information, or navigate through a multi-step workflow.

Rather than specifying every tap in advance, you describe what you want it to accomplish.

3. Repetitive mobile tasks

Many mobile workflows involve repeating the same sequence of actions: opening an app, finding a record, updating information, or navigating through several screens.

These are useful places to experiment with agent-driven automation, particularly when the process is tedious to perform manually.

The exact tasks an agent can complete will depend on the app, the UI, permissions, and the reliability of the underlying automation.

Why use a real iPhone instead of a simulator?

Simulators are valuable for development and testing. They provide a controlled environment where you can reproduce scenarios and inspect application behavior.

Physical devices matter when you need to work with the actual hardware and software environment.

A real iPhone gives you access to the device you already own, including its installed apps and existing setup, subject to the permissions and capabilities available to the automation system.

This is useful for developers experimenting with mobile agents, teams testing real-device workflows, and anyone exploring what AI can do beyond a browser.

It doesn't mean simulators are obsolete. Both approaches have their place, depending on what you're trying to build or test.

Try it yourself

If you have an iPhone and a Mac or Linux, you can connect your device to Mobilerun Cloud and start experimenting.

Connect your iPhone: Read the setup guide
Try Mobilerun Cloud: cloud.mobilerun.ai
Explore Mobilerun: mobilerun.ai
Inspect the benchmark: iOSWorld results

We're curious to see what developers build with this.

What would you want an AI agent to do on your iPhone that you can't easily automate today?

That's probably the most interesting question to explore next.

I Solved the Same Gmail Problem Two Ways Without Noticing

Thu, 29 Oct 2026 13:52:12 +0000

This is the third post from my n8n intake classifier, a practice project for a fictional automation agency that I built with an AI collaborator. The first was about the classification prompt. The second was about ambiguous, invalid and system_error. This one is about the wiring after classification: where logging goes, what the Gmail node does to your data, and a bug I only found by opening real inboxes. The workflow is in the GitHub repository.

A quick orientation: n8n is a workflow automation tool, and a workflow is built from nodes, each one a single step. The ones that matter here are Switch (sends an item down one of several paths), Set (reshapes the data) and Gmail (sends an email).

Where logging was supposed to go

After classification, a Switch node sends each submission down one of five paths, and each path sends emails. Every submission also gets logged to Google Sheets. For this phase I planned to work the way I had in the earlier ones: Sheets first, then emails, one branch at a time.

Before building anything, I caught a conflict. Logging is the same logic on all five paths, and only the data changes. Putting it first inside each branch meant five copies of one node, or converging after Sheets and then branching again to send category-specific emails. Neither made sense. So I flipped the order: build the emails first, since those differ per category, and let all five paths converge on one shared Sheets node at the end.

Gmail replaces your data

The first branch I built showed a second problem. When the Gmail node sends an email, the item it passes on is Gmail's own send confirmation, not the submission. Name, Email and description were gone by the time anything downstream needed them. The LLM Chain node had done the same thing to me earlier.

In the ambiguous/system_error branch, I added a Set node right after the internal notification to rebuild one clean object. The IF node and both client emails read from that, instead of each reaching back to whichever earlier node had the data. In simple_automation, I added a Set node after the client email to rebuild the object before it reached the shared Sheets node.

Noticing I'd solved it twice

While wiring the final Sheets node, I looked at the ambiguous/system_error branch and saw it fed Sheets from two points off the same rebuild node, one path through the client emails and one straight to Sheets. That wasn't a bug. The email path never reconnected to Sheets, so nothing was logged twice. But it showed me I had solved the Gmail problem two different ways. Everywhere else I rebuilt the data after the email. In this branch I branched before the email, because Sheets never needed anything the email step produced.

Moving logging upstream

That comparison pointed at something bigger. Every branch converged on one Sheets node, so there was no reason logging should depend on any email succeeding. A Gmail send can fail for reasons that have nothing to do with the submission.

I moved the Sheets connection to the two points right after classification: one for a successful classification and one for the failure handler. Both now feed the Switch and Sheets in parallel. Two side effects followed. has_partial_intent only had to be added in two places instead of four, and I could delete the end-of-branch Set nodes that existed only to feed the old Sheets wiring.

Before deleting any of them, I checked each one. Some still fed a client email's own data, and removing one of those would have broken a client-facing email without touching Sheets. I kept those.

The final build still contains both patterns. The ambiguous/system_error branch has its rebuild node, and the other client emails reach back to earlier nodes by name:

={{ $('Route: By Classification Category').item.json.Email }}

I haven't compared whether one pattern is more robust than the other. What changed is that logging no longer depends on either.

Checking real inboxes

After the rewiring, I retested every branch individually and checked real inboxes, not just node output. That caught a bug in the ai_workflow branch: the internal notification and the client email had their destinations swapped. The internal-only message went to the client, and the client's confirmation went to the team.

Both emails sent without errors, so nothing had failed that would make me suspect a problem. Only who received what showed it. I then confirmed the simple_automation branch had no swap, since I'd used the same inbox check there.

My notes don't record how the swap got there, or whether the rewiring caused it, so I won't guess. The current build sends each internal email to the team address and each client email to the submitter.

A test case I wrote wrong

While testing ambiguous, my first case was a deliberately vague description. It came back as invalid, and I took that as a bug. Reading the reasoning showed the classifier was right. Vague wording alone doesn't give any category a specific signal to rest on, which is a different situation from two categories each being concretely supported. I wrote a sharper case with explicit signals for both ai_workflow and custom_integration, and that one returned ambiguous.

What this doesn't show

Every test used descriptions I wrote. A forced classification failure does produce a row in the sheet, with the has_partial_intent cell empty, because the model never produced a value on that path. I did not test what happens if the Sheets step itself fails.

What I take from it is narrow: logging shouldn't wait on anything that can fail for unrelated reasons, and a branch that sends emails isn't tested until I've read the emails.

My quality gate wasn't strict. It was dead.

Tue, 27 Oct 2026 21:03:40 +0000

There is a job in my CI called judge. It reads the monthly issue my content pipeline writes, scores it against a rubric with five criteria, and blocks the merge if anything comes back at 2 out of 5 or lower. An LLM grading an LLM, with a written policy about what counts as broken.

It went red on a content PR this week. My first thought was that the piece was weak. My second thought, about four minutes later, was worse: this gate had been red on every content PR for a while, and I had been reading that as a high bar.

It wasn't a high bar. The job never reached the rubric at all.

Error: anthropic messages -> 400: output_config.format.schema:
For 'integer' type, properties maximum, minimum are not supported

The judge asks the model for structured output, and the schema it sends had this in it:

voto: { type: "integer", minimum: 1, maximum: 5 },

Which is correct JSON Schema, and which the structured output layer rejects. The request never made it to the model. The job exited 1 before scoring a single word.

A gate that cannot go green is not enforcing anything. It has the same effect on your pipeline as continue-on-error, except it also makes you feel virtuous while it does nothing.

The error message named half the problem

The obvious fix is to delete minimum and maximum and move on. I nearly did. What stopped me was noticing that the schema had a second kind of constraint in it:

motivo: { type: "string", maxLength: 300 },

Length constraints are rejected too. maxLength, minLength, pattern, minItems, all of it. My schema had three of them, and the 400 mentioned none, because validation stops at the first failure. If I had fixed what the message named, I would have pushed, waited for CI, and collected the next 400. Then the one after that.

This is a general property of error messages, not a quirk of one API: they report the first thing that broke, not the set of things that are broken. The fix that only addresses what the message says is a fix sized to the message, not to the defect.

The other thing worth knowing here: the Python and TypeScript SDKs strip unsupported constraints for you before the request goes out. My pipeline is zero-dependency and calls the API with native fetch, so nobody was stripping anything. If your SDK has been quietly saving you, you will find out the day you drop it.

So the test is about the contract

I could have written a test asserting no minimum on integers. It would have passed, and it would have been useless three weeks later when someone adds a pattern to a string.

Instead the accepted and rejected keywords are written down once, and every schema I send to the API gets checked against them:

const RIFIUTATE = new Map([
  ["minimum", "numeric constraint"],
  ["maximum", "numeric constraint"],
  ["maxLength", "length constraint"],
  ["pattern", "string constraint"],
  // ...
]);

export function keywordRifiutate(schema, path = "$") { /* walks the tree */ }

It walks nested schemas, and it knows that inside properties the keys are my field names rather than schema keywords, so a field genuinely called pattern doesn't trip it.

On first run it found sixteen violations across the judge schema. Not two. My generation schema, checked at the same time, was already clean, which I would not have bet on.

There is a second check next to it that lists keywords the contract doesn't mention. It fails rather than allowing them, which sounds aggressive for something the API might accept fine. The reason is that I want the moment where somebody adds an unfamiliar keyword to be the moment somebody reads the docs, instead of the moment CI goes red for a reason nobody connects to the schema.

Where the constraint went

The rubric still runs on a 1 to 5 scale. That range now lives in the two places the API can't reject it.

The prompt describes it, with each score defined. And the code treats an out-of-range score the way it already treats a missing one:

const fuoriScala = (v) => !Number.isInteger(v) || v < 1 || v > 5;

Fail closed. If the model returns a 7, the rubric is unreadable, and an unreadable rubric doesn't promote anything. That was already the policy for a criterion the model forgot to fill in. A score outside the scale is the same class of problem, so it gets the same answer.

Moving a constraint out of a schema usually means giving it up. Here it just meant enforcing it somewhere with a worse reputation and better reach.

What I'd check on your own pipeline

Grep your CI history for a job that has never been green. Not "was red today", never green at all, or not since some commit that had nothing to do with it. That job is not protecting you, and it is currently costing you the specific kind of comfort that comes from thinking it is.

Mine ran for weeks. It was the most reassuring line in the workflow file.

Organization-Wide EC2 DNS Automation with EventBridge & AWS Config Aggregator: One Rule Per Account

Tue, 27 Oct 2026 19:19:28 +0000

🌐 Organization-Wide EC2 DNS Automation with EventBridge and AWS Config Aggregator: One Rule Per Account

TL;DR

Detecting EC2 launches and terminations across a whole AWS Organization for DNS is not the five-minute single-account job it looks like.

The EC2 state-change event carries only an instance ID and a state, no IP, so it is useless for DNS on its own.

A hub-and-spoke design keeps the per-account footprint to a single EventBridge rule; all logic lives in one hub account.

The hub enriches each event by querying the AWS Config Aggregator you already run, which holds every instance's IP, tags, and state org-wide. No new data pipeline.

An aws:PrincipalOrgID resource policy on the hub's custom bus gives cross-account fan-in without per-account config.

SQS between the rule and the Lambda absorbs bulk launches and gives you retries plus a dead-letter queue.

How to detect every EC2 launch and termination across an entire AWS Organization, and turn it into automated DNS registration, without deploying repeated infrastructure in every account.

I spent longer than I would like to admit staring at this problem before the answer got simple. So if you are wiring up DNS across an AWS Organization right now, maybe this saves you a weekend.

Here is the short version of what I landed on. I needed near real-time DNS registration for every EC2 instance across a multi-account, multi-region org, feeding an on-prem enterprise DDI system (think Infoblox). The two obvious ways to do it both annoyed me: one puts infrastructure in every account, the other leans on a fragile cross-account API-scraping job.

What I used instead is a hub-and-spoke event setup:

Each spoke account gets exactly one EventBridge rule. That is the whole footprint.
One hub account does everything else: a custom event bus, an SQS queue, one Lambda.
The Lambda fills in the missing details by querying the AWS Config Aggregator, which, and this is the part I almost missed, already has every instance's IP, tags, and state for the entire org. No new data pipeline required.

Onboarding a new account came down to a one-line deploy. Below is the whole thing: the architecture, why I made the calls I made, and the code.

The problem (why the single-account version does not scale)

In one account this is a five-minute job. EC2 fires a state-change event, you point an EventBridge rule at a Lambda, done. I have written that Lambda a dozen times.

Across an organization it falls apart for a few reasons:

Instances come up in dozens of accounts and several regions.
The people who run DNS are not the people who own the workload accounts, so "just add it to the account" is not really on the table.
The EC2 state-change event does not include the IP address. You get an instance ID and a state. That is it. Useless for DNS on its own.
Nobody wants to deploy, version, and babysit a Lambda plus queue plus IAM role in every account just to catch these events.

The usual reason you end up here is a move to an enterprise DDI platform. Every instance that boots needs a DNS record, every instance that dies needs its record cleaned up, org-wide, in near real-time, with as little junk in each account as you can manage.

So two things really drove the design:

Adding an account should be almost free.
The IP is not in the event, so I have to look it up, and that lookup cannot be flaky.

The approaches I threw out

Option A: put the whole stack in every account. Rule, queue, Lambda, IAM role, shipped everywhere with StackSets. It works. But now you own N copies of the same code, and every bug fix or IAM tweak is an N-account rollout. I have maintained fleets like that. No thanks.

Option B: a central poller that assumes a role into the source account and calls DescribeInstances for the IP. Logic is centralized, which is nice, but you need an assume-role trust in every account and you are paying a cross-account API hop on every single event. More IAM surface, more things to break.

Option C: hub-and-spoke, enriched from the Config Aggregator. This is the one. All the logic sits in the hub. Spokes just forward. And instead of building anything to fetch the IP, the hub asks the Config Aggregator, which is already sitting there aggregating EC2 config (IP, tags, state) from every account and region.

Option C won for a boring but decisive reason: the hard part, the enrichment data, already existed. I did not have to build it. I just had to notice it was there.

How it fits together

Spokes forward EC2 state changes to the hub's custom bus; the hub enriches via the org Config Aggregator, then calls the DDI system. Spokes are dumb, the hub is smart, and the data already exists. That is the whole idea in one line.

That second hub rule is easy to forget, by the way. If you only listen on the custom bus, the hub account's own instances never get DNS records, because they never leave home to reach the custom bus. Ask me how I know.

Filling in the blanks

Most single-account tutorials skip this bit, which is exactly the bit that matters at scale. Here is what the event actually gives you:

{
  "source": "aws.ec2",
  "detail-type": "EC2 Instance State-change Notification",
  "detail": {
    "instance-id": "i-1234567890",
    "state": "running"
  }
}

An ID and a state. No IP, no tags, no hostname. So the Lambda goes and gets the rest, from the aggregator, not from the source account.

The nice thing: the aggregator is org-level, so one query resolves an instance no matter which account or region it lives in. No assume-role, no per-account permissions to manage.

The code

Everything here is vendor-neutral and anonymized. Swap the Infoblox call for whatever you actually talk to: Route 53, a CMDB, an IPAM API.

The spoke's one and only rule (Terraform)

This is the entire per-account footprint. Ship it with StackSets or a Terraform module.

# --- Deployed in EVERY spoke account/region ---

resource "aws_cloudwatch_event_rule" "forward_ec2_state" {
  name           = "forward-ec2-state-to-hub"
  description    = "Forward EC2 running/terminated events to the hub account"
  event_bus_name = "default"

  event_pattern = jsonencode({
    source        = ["aws.ec2"]
    "detail-type" = ["EC2 Instance State-change Notification"]
    detail = {
      state = ["running", "terminated"]
    }
  })
}

resource "aws_cloudwatch_event_target" "to_hub_bus" {
  rule           = aws_cloudwatch_event_rule.forward_ec2_state.name
  event_bus_name = "default"
  arn            = "arn:aws:events:${var.region}:${var.hub_account_id}:event-bus/ec2-dns-hub-bus"
  role_arn       = aws_iam_role.eventbridge_cross_account.arn
}

# Minimal role that lets EventBridge PutEvents to the hub bus
resource "aws_iam_role" "eventbridge_cross_account" {
  name = "eventbridge-forward-to-hub"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "events.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy" "put_events" {
  role = aws_iam_role.eventbridge_cross_account.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "events:PutEvents"
      Resource = "arn:aws:events:${var.region}:${var.hub_account_id}:event-bus/ec2-dns-hub-bus"
    }]
  })
}

The hub's custom bus, with an org-scoped resource policy

This policy is the thing that makes "one rule per spoke" actually work: any account in the org can publish, and the hub needs zero per-account config.

# --- Deployed ONCE in the hub account ---

resource "aws_cloudwatch_event_bus" "hub" {
  name = "ec2-dns-hub-bus"
}

resource "aws_cloudwatch_event_bus_policy" "allow_org" {
  event_bus_name = aws_cloudwatch_event_bus.hub.name
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "AllowOrgAccountsToPutEvents"
      Effect    = "Allow"
      Principal = "*"
      Action    = "events:PutEvents"
      Resource  = aws_cloudwatch_event_bus.hub.arn
      Condition = {
        StringEquals = {
          "aws:PrincipalOrgID" = var.aws_org_id
        }
      }
    }]
  })
}

Do not skip the aws:PrincipalOrgID condition. It scopes that Principal = "*" down to your organization instead of, you know, the entire internet. It is the one line standing between "elegant pattern" and "open event bus."

Rules, queue, and Lambda wiring (hub)

resource "aws_sqs_queue" "events" {
  name                       = "ec2-dns-events"
  visibility_timeout_seconds = 120
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.dlq.arn
    maxReceiveCount     = 5
  })
}

resource "aws_sqs_queue" "dlq" {
  name = "ec2-dns-events-dlq"
}

# Rule on the custom bus (events from spokes)
resource "aws_cloudwatch_event_rule" "hub_custom" {
  name           = "ec2-state-custom-bus"
  event_bus_name = aws_cloudwatch_event_bus.hub.name
  event_pattern = jsonencode({
    source        = ["aws.ec2"]
    "detail-type" = ["EC2 Instance State-change Notification"]
    detail        = { state = ["running", "terminated"] }
  })
}

resource "aws_cloudwatch_event_target" "custom_to_sqs" {
  rule           = aws_cloudwatch_event_rule.hub_custom.name
  event_bus_name = aws_cloudwatch_event_bus.hub.name
  arn            = aws_sqs_queue.events.arn
}

# Second rule on the default bus catches the hub account's OWN instances
resource "aws_cloudwatch_event_rule" "hub_default" {
  name           = "ec2-state-default-bus"
  event_bus_name = "default"
  event_pattern = jsonencode({
    source        = ["aws.ec2"]
    "detail-type" = ["EC2 Instance State-change Notification"]
    detail        = { state = ["running", "terminated"] }
  })
}

resource "aws_cloudwatch_event_target" "default_to_sqs" {
  rule = aws_cloudwatch_event_rule.hub_default.name
  arn  = aws_sqs_queue.events.arn
}

resource "aws_lambda_event_source_mapping" "sqs_to_lambda" {
  event_source_arn = aws_sqs_queue.events.arn
  function_name    = aws_lambda_function.dns_registrar.arn
  batch_size       = 10
}

The enrichment Lambda (Python)

This is the heart of it: resolve the instance against the Config Aggregator, then act on the state.

import json
import boto3

config = boto3.client("config")

AGGREGATOR_NAME = "OrganizationConfigAggregator"

def get_instance_details(instance_id: str) -> dict | None:
    """Resolve IP, tags, account, and region from the org Config Aggregator."""
    expression = (
        "SELECT resourceId, accountId, awsRegion, "
        "configuration.privateIpAddress, "
        "configuration.publicIpAddress, tags "
        f"WHERE resourceId = '{instance_id}' "
        "AND resourceType = 'AWS::EC2::Instance'"
    )
    resp = config.select_aggregate_resource_config(
        Expression=expression,
        ConfigurationAggregatorName=AGGREGATOR_NAME,
        Limit=1,
    )
    results = resp.get("Results", [])
    return json.loads(results[0]) if results else None


def handler(event, _context):
    for record in event["Records"]:
        body = json.loads(record["body"])
        detail = body["detail"]
        instance_id = detail["instance-id"]
        state = detail["state"]

        details = get_instance_details(instance_id)
        if not details:
            # Terminated instances may already be gone from the aggregator;
            # fall back to event data for deregistration.
            if state == "terminated":
                deregister_dns(instance_id)
            continue

        ip = (
            details.get("configuration", {}).get("privateIpAddress")
            or details.get("configuration", {}).get("publicIpAddress")
        )

        if state == "running" and ip:
            register_dns(instance_id, ip, details.get("tags", []))
        elif state == "terminated":
            deregister_dns(instance_id)


def register_dns(instance_id, ip, tags):
    # Replace with your Infoblox / Route 53 / IPAM call.
    # Infoblox example: POST to the WAPI record:a endpoint.
    print(f"REGISTER {instance_id} -> {ip}")


def deregister_dns(instance_id):
    print(f"DEREGISTER {instance_id}")

One thing worth calling out: that SELECT against the aggregator resolves a resource across every account and region in a single call. That is the capability that collapses the whole cross-account enrichment headache into a one-liner. I keep coming back to it for other problems now.

And notice the fallback in the handler. A terminated instance has often already dropped out of the aggregator by the time you look, so you cannot rely on the lookup for deregistration. You fall back to the instance ID from the event. Small thing, but it will bite you in testing if you miss it.

Why there is an SQS queue in the middle

You can target the Lambda straight from the rule, and for a demo I would. In production I put SQS in between on purpose:

A bulk launch, a scale-out, a StackSet rollout, can throw hundreds of events at you at once. SQS soaks that up and lets the Lambda drain at its own pace instead of getting hammered.
When Infoblox or the aggregator has a bad minute, messages retry and eventually land in a DLQ you can actually look at. Nothing quietly disappears.
Batching. Ten events per invocation, fewer cold starts, lower cost.

Decoupling ingest from processing is most of what separates "worked in the demo" from "still working at 2am during a mass launch."

What actually came out of it

Detection and DNS updates happened within seconds, across the whole org.
Adding an account or region was a single forwarding rule. No Lambda, no queue, no Config setup per account.
Registration and cleanup were fully automated across the instance lifecycle, nobody touching DNS by hand.
Cost tracked instance activity, not the clock, because there is no idle compute.
The shape is reusable. Same hub-spoke plus aggregator-enrichment works for CMDB sync, security tagging, IPAM updates, anything org-wide and event-driven.

The part worth stealing

Take Infoblox out of the picture and you are left with a pattern I now reach for often:

Fan org-wide events into one hub, then enrich them from a data source the organization already has, instead of building a new one.

Two moves do the work:

A custom event bus with an aws:PrincipalOrgID resource policy gives you cross-account fan-in and a one-rule spoke footprint.
The Config Aggregator, used as an enrichment lookup, resolves any resource in any account or region without an assume-role fan-out.

So the next time you are about to copy the same Lambda into 40 accounts, stop and ask whether a fan-in plus an aggregator you already run could do it with one rule per account instead. Usually it can.

Wrapping up

Honestly, none of the individual pieces here are clever. Cross-account EventBridge is documented. Config aggregators are documented. The win was in composing them so the per-account cost dropped to near zero and the enrichment data was something we already had lying around. That is where most of the good architecture calls seem to live, not in the shiny new component, but in the one you talked yourself out of building.

If you end up adapting the enrichment step to Route 53, a CMDB, or your own IPAM, I am happy to talk through it in the comments.

Why the LLM in my automation agent never clicks anything

Tue, 27 Oct 2026 16:57:45 +0000

I'm a computer engineering student in Manaus, Brazil, and for my research project I've been building ANCHOR, a web automation agent: you describe a task in plain language ("Register Maria Silva, IT department, contractor, accept the terms and save"), and it runs the task in the browser. Everything runs locally, with small models (Qwen 3.5, 4B and 9B, through Ollama) on a GTX 1050 Ti with 4 GB.

This post is about the one design decision that made the biggest difference, and a few things I learned by measuring everything.

The problem

Classic RPA depends on fixed selectors written by a developer:

page.locator('[data-test="add-to-cart"]').click()

It works until the page changes, and every automation needs someone who codes, far from the person who actually knows the task.

The trendy answer is to put an LLM in control: it looks at the page and decides where to click. With small models, that has a serious problem, which I measured (below): the model says it's done when it isn't.

The decision: the model only plans

In ANCHOR, the model never clicks anything. It gets the request and a summary of the page (the elements, numbered), and returns a plan: goals and steps, using the elements' names ("fill Full name", "check Contractor", "click Save registration").

A deterministic engine, with no AI, carries it out:

A heuristic finds each element from the step's description, combining text, label, role and context (synonyms, nearby text), and refuses when it isn't sure.
When it refuses, the user decides: the candidates are numbered on the page, and you pick one (or click the right element).
The choice is remembered, so the next run doesn't ask.
Each action's effect is checked (did the page change? did the field keep the value? did an error appear?), and the end of the run is checked against the request.

In the GIF, the site changed after the automation was saved ("Add to cart" became "Add to bag"). Instead of guessing, ANCHOR asks which button to use, remembers the answer, and the next run goes on its own.

Learn once, replay without the model

A task that worked can be saved. The first run plans with the model (about 70 seconds on my GPU); the next ones replay the approved plan without calling the model, in about 3 seconds, even once per row of a spreadsheet. When the site changes and a saved step breaks, the automation recovers and records what it changed, and that record can be reviewed and undone.

What the measurements showed

I built a resilience benchmark: 30 tasks on pages altered in 5 levels (renamed IDs, synonyms, restructured layouts, cookie banners and hidden sections, lookalike decoys with injected instructions), 150 runs per executor and model, with no user to help:

Executor	Tasks done	False successes
Fixed-selector script (classic RPA)	53%	0
LLM in control (4B / 9B)	68% / 72%	33 / 41
ANCHOR (4B / 9B)	82% / 84%	2 / 1

The column that surprised me most was false successes: the LLM-in-control agent claimed it had done the task, without doing it, in about one run in four. For whoever relies on the automation, that's worse than failing, because nobody finds out.

ANCHOR's weak spot is pages with part of the content hidden behind a "Show more" button (47%, vs 57–60% for the LLM in control). And an honest caveat: these are development numbers, where I tuned the system looking at the tasks. For 1.0, there's a closed set of 80 requests written by colleagues who never saw the project, which will run only once, at the end.

Three lessons

1. Re-measure everything after every change. The first full benchmark run revealed four bugs no test had caught (for example, the barrier against destructive actions let a "Delete all" through when the request was "delete Bruno Lima"). And two of my first fixes created new problems, which only showed up because I re-ran the other evaluations too.

2. A prompt change affects tasks that have nothing to do with it. When I added table extraction, I put two lines in the prompt explaining the new actions. The 4B model started stopping a search after filling the box, and the 9B one left the contract type out of a registration. The fix was to show those lines only when the request is about reading data; for every other request, the prompt is identical, byte for byte, to the previous version.

3. Never put your password in a request to an AI. Testing on LinkedIn, I wrote my e-mail and password in the request, and it typed them. The password never left my computer, but it went through the model, which shouldn't happen. That became version 0.3.1: ANCHOR never types a password, refuses a request with a password before it reaches the model, and when a task needs a login, it stops and waits for you to log in by hand (the session is kept for the next runs).

Try it

The project is on GitHub, with the setup steps in the README:

https://github.com/LucasDantas2701/ANCHOR

Testers and opinions are very welcome, especially failure cases on real sites: that's the most useful feedback. The next version (0.4) adds file downloads and uploads, new tabs and iframes.

Disclosure: the code was written with help from an AI assistant (Claude), which also helped me write this post; the project, the decisions and the evaluation are mine. The code is source-available (PolyForm Strict): you can read and use it, but not modify or redistribute it.

A week of green runs, and the pipeline was waiting for me

Tue, 27 Oct 2026 16:02:11 +0000

On 1 September at 10:57 UTC the monthly ingest ran. It opened issue number 3 of the magazine, picked the vertical from the source registry, wrote 19 candidate sources into Postgres with stage = 'discovery', and opened a GitHub issue telling me it was my turn.

Every morning after that, the daily job ran and succeeded. Eight consecutive green runs, from the first of the month to the eighth. The article count for September stayed at zero the whole time.

The gate was doing its job

The daily job does not decide anything by itself. It asks the database which stage to run, and the answer depends on a view:

SELECT id, issue_id, source_url, tier, independent
FROM signals
WHERE stage = 'verify' AND (tier = 1 OR tier = 2 AND independent);

Nothing satisfies that view until I sit in Supabase Studio and tag the sources by hand. Tier 1 is a primary source, a regulator or the organisation that ran the thing. Tier 2 counts only when it is independent of whoever it describes, which rules out a consultancy writing up its own project as a case study.

That judgement is mine on purpose. It is the editorial bar of the magazine, and I did not want a model deciding what counts as proof of anything.

So the decision function found a draft issue with no verified signals, returned niente, and printed its reason to stderr:

advance: signal in attesa di verifica in Studio

Then it exited zero, which is correct. There was nothing for it to do.

What my alarms actually watch

I have three, and I was fairly pleased with them.

A cron that fails opens a GitHub issue on its own. A cron that never starts is caught by a daily watchman that asks the GitHub API when each schedule last fired, because a schedule that GitHub has quietly disabled produces no failure to report. And because a watchman inside the same failure domain is not a watchman, that job also checks in with a Sentry monitor that alarms on silence from outside GitHub.

Between them they cover a job that breaks and a job that never runs. Neither of those happened. What happened was a job that ran, succeeded, and did nothing, for seven days, because it was waiting for a person who had not noticed.

The information was already there

The part I find annoying is that nothing was hidden. The reason is written every single morning, in the run log, in Italian, on stderr. The job knows exactly why it is idle and says so out loud.

What it does not know is how long it has been saying it. niente on the second of the month and niente on the eighth are the same string, and the only thing that separates them is a week of my attention going somewhere else. No alarm reads that log line, and no counter turns it into a duration.

Green means the machine is healthy. I had been reading it as "the work is moving", and those are different claims.

How it ended

On the eighth I opened Studio and tagged 11 of the 19 sources: two from the regulator as tier 1, nine analyst reports as tier 2 and independent. I left out a vendor case study, which fails the independence test by construction, and seven security bulletins whose scraped body is only a title.

After that the pipeline did the rest in a few minutes. Generate wrote the piece from eight sources, embed rebuilt the chunks, export produced the two markdown files, and the judge on the pull request failed me for weak attribution, which is a story for another post.

The September issue went out a week late. Nothing had broken, and every run had been green.

So I do not need a fourth alarm. I need the daily job to count the mornings it has spent answering niente, and to say that number where I actually look.

How I Built a 24/7 AI DevOps Coding Agent for About CAD 200

Tue, 27 Oct 2026 05:18:01 +0000

Hermes + Claude Code + Telegram on a cheap always-on thin client.

Hi, I'm Amir

I'm a DevOps engineer, and a surprising amount of my time goes into work that is important but repetitive.

A server needs patching. A CI/CD pipeline fails. A script needs a small change. A Terraform module needs an update. A tool I built needs one more feature. Tests need to be run, branches need to be checked, and somebody still has to make sure the generated code actually works.

None of those jobs is necessarily difficult on its own. The annoying part is the constant context switching.

I kept thinking:

What if I had a small AI worker that was always online, understood my repositories, could call a real coding agent, verify the result, manage Git, and report back to me on my phone?

That is what this setup became.

I use Hermes as the agentic AI harness and orchestrator. Hermes is connected to OpenRouter, where I use a low-cost DeepSeek Flash v4 model for the orchestration layer. When real coding work is needed, Hermes delegates that work to the Claude Code CLI, which is my main coding agent.

The split is intentional:

Claude helps me think through the problem. Claude Code does the main coding. Hermes runs the workflow, performs QA, manages Git, pushes the repo, and keeps me updated through Telegram.

This is not meant to replace me as an engineer. It is meant to remove the repetitive overhead around the work.

How I divide the work between Claude, Hermes and Claude Code

I deliberately do not ask one AI agent to do everything.

When I have a new idea, bug, or feature, I normally start by talking it through with Claude. I explain what I want, what is currently broken, what constraints matter, and what I do not want changed.

Claude helps me turn that into a clear, compact prompt for Hermes.

Then I hand the task over.

Claude: planning and shaping the task

Claude is where I usually work through questions like:

What exactly should change?
What should stay untouched?
What edge case am I forgetting?
What is the smallest useful test?
What should count as PASS?
What instructions does Hermes actually need?

I don't want a giant five-page prompt. By the time I send the task to Hermes, the thinking should already be distilled into something actionable.

Hermes: orchestration, QA and Git management

Hermes is my manager layer.

Its job is not to out-code Claude Code. Its job is to keep the job moving.

In my workflow Hermes is responsible for things like:

checking the current repo and branch
launching the coding agent
monitoring the task
running the relevant tests itself
verifying that the result actually matches the request
checking Git status
committing only after the task passes
pushing the branch
reporting PASS / FAIL, issues and next steps back to Telegram

That separation matters to me:

The agent that writes the code is not the same layer that decides the job is finished.

Claude Code: the main coding agent

When the work gets into the actual codebase, Claude Code CLI is my primary coding agent.

That is where I want the heavier coding intelligence spent:

reading the codebase
implementing features
fixing bugs
changing tests
debugging failures
reasoning about implementation details

Hermes stays relatively lightweight and cheap. Claude Code does the expensive coding work only when I actually need it.

A real prompt from my workflow

Here is a real example.

After discussing the issue with Claude, this was the kind of short prompt I sent to Hermes:

In text form:

On feature/patch-all: after app restart, an analysis left RUNNING is not
marked INTERRUPTED and Analyze/Patch stay disabled. Startup recovery from
faa2ae6 isn't working on a real DB (schema v7, existing runs). Fix + test
with a DB containing a RUNNING analysis before startup.
Full suite + ruff. Commit after PASS, push. Report PASS/FAIL | issues | next.

I like this kind of prompt because it is short but still gives Hermes everything it needs:

where the problem is → what the failure looks like → what must be tested → when Git operations are allowed → what I want reported back.

Hermes does not just trust the coding agent

This is the part that made the setup useful for me rather than just interesting.

After Claude Code finishes, Hermes still has work to do.

Here is a real result from my Telegram workflow:

In this example Hermes exercised the fallback path, brought up the required containers, reran the integration test against the real environment, cleaned things up, and then handled the Git commit.

That is exactly the kind of repetitive workflow I want the orchestrator doing for me.

I want Claude Code focused on implementation.

I want Hermes focused on:

implement
   ↓
verify
   ↓
test
   ↓
inspect
   ↓
commit
   ↓
push
   ↓
report

Telegram is my remote control

Telegram is what makes the whole setup feel different from simply running an AI coding tool on my laptop.

I can be somewhere else and send something like:

Check the latest branch.

Have Claude fix the regression.

Run the targeted tests.

If everything passes, commit and push.

Report PASS/FAIL, issues, and next.

Then I can put my phone away.

The actual work is happening on the thin client at home.

I don't need a remote desktop session. I don't need VS Code open. I don't need my laptop to stay awake.

Telegram is just the control surface.

The hardware cost me about CAD 200

I deliberately did not build an expensive home server for this.

The machine only needs enough resources to run Linux, Hermes, Git, development tools, containers when needed, and the local Claude Code CLI. The heavy LLM computation happens remotely.

I bought a used Dell Wyse 5070 thin client for about CAD 120.

Part	My setup	Approx. cost
Thin client	Dell Wyse 5070	CAD 120
CPU	Intel Celeron J4105, 4 cores	included
RAM	4 GB physical RAM	included
Internal storage	32 GB	included
Wireless	Linux-compatible USB Wi-Fi adapter	CAD 20
External storage	256 GB external SSD	CAD 60
Approx. total		CAD 200

The original 32 GB storage was too small once Docker, repositories, package caches and development tools entered the picture.

I mounted the external SSD at:

/data

and moved the storage-heavy workloads there:

/data
├── docker
├── containerd
├── projects
└── swapfile

My project path points to the SSD:

~/projects -> /data/projects

The Wyse has 4 GB of physical RAM, so I also added a 4 GB swap file on the external SSD.

That gives the OS 4 GB RAM + 4 GB swap to work with.

Swap is obviously not the same as real RAM, but for a cheap orchestration box it gives me useful headroom during temporary spikes.

Installing Hermes on Ubuntu 26.04

I run the box on Ubuntu 26.04.

For Hermes itself, I followed the official installation method from the Hermes Agent website.

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

After installation, the important pieces in my setup are:

Hermes Agent running on the thin client.
OpenRouter as the model provider for Hermes.
DeepSeek Flash v4 as my low-cost orchestration model.
Telegram connected so I can talk to Hermes remotely.
Claude Code CLI installed and authenticated as the main coding agent.
Git / GitHub access configured so Hermes can manage the repository workflow.

The main idea is simple:

Spend the expensive model on the coding problem. Keep orchestration lightweight.

What happens when the first coding attempt fails?

One thing I did not want was this:

Claude Code says "done"
        ↓
Hermes trusts it
        ↓
bad code gets pushed

That defeats the point of having an orchestration layer.

My preferred flow looks like this:

If QA fails, Hermes has evidence it can hand back to the coding agent:

failing tests
command output
wrong behavior
dirty Git state
integration failure
missing expected changes

The coding agent gets another chance to fix the actual failure.

Only after Hermes can reproduce a passing result does the workflow move to commit and push.

I find that much more useful than simply asking the coding model:

"Are you sure it works?"

How I keep the running cost under control

The hardware cost is only one part of the story.

What matters more over time is where I spend model tokens.

Hermes mainly needs to do things like:

inspect the current state
decide which tool or agent should run next
wait for a result
run tests
check Git status
retry when something fails
report back to me

For that layer I use a cheaper model through OpenRouter.

I save Claude Code for the part where the extra intelligence actually matters: understanding and changing the codebase.

Cheap model
    ↓
orchestration / routing / checking

Expensive coding model
    ↓
used only when real coding is required

I also don't need to pay for a cloud VM just to keep the agent online because the Wyse is doing that job at home.

My ongoing cost is therefore mostly whatever I spend on Claude/Claude Code and OpenRouter usage rather than another always-on server bill.

Guardrails I use before code gets pushed

I want this system to save time, not create a faster way to break things.

Some rules I like are:

No commit before QA passes.
No push before the working tree is in the expected state.
Test the changed behavior, not just whether the code imports.
Prefer a small targeted regression test first.
Use the existing full test suite when appropriate before finalizing.
Report failures instead of hiding or working around them.
Keep production credentials and private keys outside prompts and public repos.
Do not let the coding agent silently change unrelated parts of the project.

For my personal projects, I also try not to turn every small change into a giant enterprise QA exercise.

The goal is enough verification to catch the mistake without spending more time testing than the original task was worth.

Where this setup works well — and where it doesn't

This setup is a good fit for work that is:

repetitive
repository-based
testable
scriptable
safe to perform from a development machine
easy to describe with a clear PASS/FAIL condition

Examples include:

small internal tools
bug fixes
repetitive patching utilities
CI/CD helper scripts
Terraform changes in non-production environments
report generators
automation around Git and testing

It is not something I would blindly point at production and tell:

"Do whatever you think is best."

For high-risk production changes, security-sensitive operations, destructive database work, or anything with a large blast radius, I still want explicit human review and normal change controls.

The agent is useful because it removes repetitive work.

It does not remove engineering judgment.

A few things I learned while building it

1. The orchestration machine does not need to be powerful

At first it is easy to think "AI agent" means "expensive AI hardware."

In this design, it doesn't.

The thin client mostly needs to stay online, run tools reliably, and have enough storage.

2. Separating coding from verification is valuable

Claude Code is very good at coding.

That does not mean I should automatically accept its own definition of "finished."

Having Hermes independently run the checks gives the workflow a much cleaner boundary.

3. A short prompt can be better than a huge prompt

Because I discuss the idea first, the prompt I send to Hermes can stay focused.

That reduces noise and makes failures easier to understand.

4. Reliability matters more than raw speed

The Wyse is not fast.

But it is always there.

For this use case, always available + predictable is more valuable to me than having a much faster machine that disappears when I close my laptop.

5. The best automation is the one I actually use

The biggest win is not that the architecture looks clever.

It is that I can send a task from Telegram, walk away, and come back to a tested branch instead of spending another hour doing repetitive setup and Git work.

Final thoughts

I did not build this because I wanted an AI experiment sitting in a corner of my house.

I built it because I'm a DevOps engineer and I have repetitive work.

Sometimes the right answer to a repetitive task is a Bash script.

Sometimes it is Terraform.

Sometimes it is a small Python tool.

And now, sometimes I can simply describe the problem, let my agent workflow build or fix the tool, verify the result, and give me the branch when it is ready.

My setup has a very simple division of responsibility:

I bring the problem. Claude helps shape the solution. Claude Code writes the code. Hermes manages the job, verifies it, handles Git, and reports back to me.

The Wyse provides the always-on home.

Telegram gives me access from anywhere.

The cloud models provide the intelligence.

A cheap little thin client became my 24/7 AI DevOps coding worker.

Source / setup files: Amiri83/hermis on GitHub

Original Gist: My 24/7 AI DevOps Coding Agent

Ambiguous, Invalid, or System Error?

Thu, 22 Oct 2026 11:37:02 +0000

In my previous post, I wrote about the problems I found while defining the categories for an AI intake classifier. I left ambiguous and invalid for another post.

Those two states turned out to be only part of the problem. While wiring the workflow, I also needed to distinguish a request the model could not classify from a request the model never managed to evaluate.

This is the same practice project for a fictional automation agency, built in n8n with an AI collaborator. It is not a production client system. The workflow and project notes are in the GitHub repository.

Three different reasons for not choosing a project category

The classifier had three normal project categories:

simple_automation
custom_integration
ai_workflow

But not every submission should be forced into one of them.

ambiguous means the request is usable, but the text supports more than one category. The workflow should not pretend that a guess is a confident classification. In my sharper overlap test, I deliberately included concrete signals for both ai_workflow and custom_integration. The classifier returned ambiguous.

invalid means the input does not provide enough usable project intent to assign a normal category. This does not necessarily mean the person has no genuine request. A vague but relevant message can still contain partial intent. On the other hand, an out-of-scope message may contain nothing useful to route.

system_error means classification did not complete. The workflow did not reach a decision about the request, so treating it as invalid would report something the system did not know.

The difference matters because each state calls for a different response. A real request with overlapping categories may need a person to decide. An out-of-scope submission may not need a client email. A system failure needs troubleshooting or a retry, not a judgment about the request itself.

`invalid` needed one more field

My first definition of invalid treated missing information as the main signal. That overlapped with ambiguous, because both could describe a submission that could not be assigned cleanly. I changed the distinction: ambiguous is for multiple categories supported by the text; invalid is for input that does not support a responsible category assignment.

Then I noticed that one invalid label was still hiding two different situations:

The person has a real project in mind, but the request is too vague to classify yet.
The submission is unrelated or out of scope, with no useful project intent to follow up on.

I could have tried routing by keywords in the model's reasoning text, but that would make the workflow depend on the exact wording of an explanation. I also considered a conditional schema. Because the result passed through n8n's Structured Output Parser, I did not want to assume that conditional-schema behavior would be preserved through its translation layer.

I chose a simpler, always-present boolean: has_partial_intent.

{
  "category": "invalid",
  "has_partial_intent": true
}

That keeps invalid as the category and makes the next decision explicit. It is easier for a downstream node to route on a boolean than to interpret free-text reasoning.

I tested it with three small examples:

help automating my workflow returned has_partial_intent: true. The request was vague, but it did point to a real automation need.
fix my car returned false. It was a request, but not one this intake workflow was built to handle.
I love football also returned false as unrelated input.

These examples helped check the distinction I had defined. They are not a representative dataset, and they do not tell me how often the classifier would get this right with real submissions.

A model failure is not an invalid submission

I also needed system_error for cases where classification itself failed. A network interruption or a broken model credential should not make the workflow label a valid request as invalid. The system has not made a decision about the content at all.

I tested the failure path by temporarily breaking the Gemini credentials. The workflow retried classification three times at five-second intervals, then reached the fallback route for human review. I also checked that the original submission data remained available on that path.

The ambiguous and system_error routes shared some downstream handling, but I kept the category values separate. The reason for sending something to human review is important: in one case the model made a decision that needs human judgment; in the other, it did not complete the decision.

That distinction affected the client-facing message too. For a system failure, it would have been misleading to send the same confirmation as if a normal classification had succeeded. The workflow needed to acknowledge the issue without claiming the request was invalid.

Why I used explicit routing

I had considered using an AI Agent to choose how these outcomes should be handled. I did not need another model-driven decision, though. The possible states were already known, and the workflow's job was to route each one consistently.

I used explicit Switch and IF branches instead. That made the expected paths visible in the workflow and easier to test. For the invalid case with has_partial_intent: false, I confirmed that no email was sent while the submission was still logged to Google Sheets. Logging did not depend on sending a client message.

What I can claim from these tests

I exercised a deliberately ambiguous request, vague and out-of-scope inputs, and a forced model failure. I also checked the fallback path and verified that the invalid/no-partial-intent case was logged without triggering emails.

That is evidence that these particular paths were exercised in this build. It is not proof of general classifier accuracy or production reliability. The examples were written by me, and a larger, independently labelled set of realistic submissions would be needed to measure that properly.

The useful lesson for me was that a fallback is not just a place to send everything that does not match a normal category. The workflow needs to preserve why it did not choose a category: competing interpretations, insufficient or irrelevant intent, or a failure to classify at all.

How to Set Up Automated Social Media Cross-posting for Web Content

Wed, 21 Oct 2026 17:09:31 +0000

Publishing a new blog post is only one part of content marketing. After an article goes live, it also needs to reach readers who follow your website on social media. Sharing every new article manually across multiple platforms can take time, especially when you publish regularly or manage several websites.

Automated social media cross-posting helps solve this problem. It connects your website or content management system to social media accounts so that new articles can be shared automatically or scheduled for publication through a central dashboard.

For bloggers, digital marketers, website owners, and SEO professionals, the goal is to make content distribution more consistent without creating unnecessary work. The right setup can reduce repetitive tasks, help readers discover new articles, and give your team more time to focus on writing and audience engagement.

This guide explains how to set up automated social media cross-posting, which tools to consider, how to configure a reliable workflow, and what to check before allowing automation to publish content on your behalf.

What Is Automated Social Media Cross-posting?
Automated social media cross-posting is the process of distributing content to multiple social media accounts through a connected tool or publishing workflow.

For example, when you publish a new article on your WordPress website, an automation tool can share its title, link, featured image, and accompanying message on selected social media platforms. Depending on the service and your settings, you may be able to publish immediately or schedule the social posts for later.

The process can involve a direct integration with your website, a social media management platform, or an automation service that connects different applications.

Cross-posting does not mean that every platform must receive an identical post. A blog article can remain the same while its promotional message changes to suit the audience and format of each network.

LinkedIn may be suitable for a professional summary of an industry report. Facebook may work well with a conversational introduction. Other platforms may require a different image, shorter caption, or a format that places greater emphasis on visual content.

The main objective is to reduce manual distribution while keeping each social post relevant to its destination.

Why Automate Social Media Cross-posting?

Reduce repetitive publishing tasks
Manually copying article links, preparing captions, uploading images, and publishing updates across several accounts takes time. An automated workflow can handle much of this routine work once it has been configured.

This is particularly useful for publishers who release multiple articles each week or manage content for several clients.

Maintain a consistent distribution process
A publishing workflow can ensure that eligible articles are sent to the selected social media accounts whenever the required conditions are met.

Instead of relying on someone to remember every account after publishing an article, the workflow follows predefined rules.

Automation does not guarantee that every post will publish successfully. Account permissions, platform restrictions, connection problems, and incorrect settings can interrupt the process. Monitoring remains necessary.

Help readers discover website content
Social media posts give existing followers another way to discover articles, tutorials, research, and product updates published on your website.

Cross-posting also creates a repeatable process for promoting new content. However, automated sharing alone does not guarantee more website traffic, higher search rankings, or increased engagement. Those outcomes depend on factors such as content quality, audience interest, distribution, and the performance of each post.

Support a larger content operation
Agencies, publishers, and marketing teams often work with several websites and social media accounts. A central publishing tool can help coordinate these accounts without requiring staff to repeat the same steps for every article.

The benefits depend on the platforms supported by the tool and the permissions available for each connected account.

Step 1: Identify Your Website and Social Media Accounts
Before setting up automation, list the website or websites you want to connect and the social media accounts where you intend to distribute content.

Start with the platforms that are relevant to your audience. A business blog may prioritize LinkedIn and Facebook, while a visual publisher may have different requirements.

Check the following details before choosing a tool:

The content management system used by your website.

The social media accounts you manage.

Whether you need immediate publishing or scheduled posts.

Whether each platform supports the type of content you want to publish.

Whether you need separate captions and images for different networks.

Whether you need publishing history, analytics, or team access.

These requirements determine which integration is suitable for your workflow.

Do not assume that every social media platform supports the same publishing methods. For example, Buffer documents different publishing capabilities for Facebook Pages, Instagram professional accounts, LinkedIn accounts, TikTok, and other supported channels. Some account types have notification-based publishing rather than fully automatic publishing.

Check the current support documentation for your chosen service before connecting your accounts.

Step 2: Choose a Cross-posting Tool
There are several ways to automate social media distribution. The right choice depends on your website platform, budget, preferred publishing method, and technical requirements.

Option A: Jetpack Social for WordPress
Jetpack Social is an option for WordPress publishers who want to share new posts through their website's publishing workflow.

Its documented features include connecting social accounts, automatically sharing new posts, reviewing previews, and scheduling the redistribution of previously published content. Supported networks include Facebook, Instagram, Threads, LinkedIn, Mastodon, Nextdoor, Bluesky, and Tumblr, subject to the service's current connection requirements.

To get started, install and activate Jetpack Social or activate the relevant social features through Jetpack. Connect the service to your WordPress site, then authorize the social accounts you intend to use.

Open the Jetpack Social dashboard and review the automatic sharing settings. On supported installations, you can enable automatic sharing to connected social accounts.

When preparing an article, open the social sharing controls in the WordPress editor. Select the accounts where the article should be shared and review the message and image settings.

Jetpack Social also supports post previews and, depending on the plan, customized messages and media for individual networks.

This option is worth considering if WordPress is the main publishing platform and you want to manage distribution from the article editor rather than maintain a separate workflow.

Option B: Buffer for Centralized Publishing
Buffer is a social media management platform that supports publishing to multiple connected social channels.

Instead of relying entirely on a direct website integration, you can use Buffer to prepare and schedule social posts from a central dashboard. Its supported channels include Facebook Pages, Instagram business and creator accounts, LinkedIn Pages and profiles, Pinterest, TikTok, Threads, Bluesky, and other networks, with publishing capabilities varying by account type and plan.

To use Buffer, create an account, connect the social channels you manage, and confirm that each account is available for the publishing method you require.

Next, prepare a post containing the article URL, a suitable caption, and any required media. Select the intended channels and schedule the posts using your publishing calendar.

If you want new website articles to enter an automated workflow, determine whether your website, RSS feed, or another integration can connect to the services you use. Do not assume that connecting social accounts alone automatically shares every article published on your website.

Buffer also documents that posts published through its service do not automatically cross-post to other social networks simply because cross-posting is enabled in a separate social platform's native settings. Select the required destinations in your publishing workflow.

Option C: RSS-Based Automation
RSS, or Really Simple Syndication, provides a feed of information from a frequently updated website. Many blogs provide RSS feeds that other services can monitor for new content.

An RSS-based workflow can use a new feed item as a trigger for an automation. The workflow can then pass available information, such as an article title and URL, to a connected publishing service or another supported action.

Zapier documents RSS-based workflows that can use feed items to trigger automated processes.

To use this method, confirm that your website provides a working feed and that the automation service can read it. Configure the workflow to detect new items, map the available article details to the next step, and select the publishing destination supported by your connected applications.

The exact setup depends on the services involved. Some combinations require additional configuration, filters, or a separate social publishing tool.

RSS-based automation is useful when you need to connect applications that do not share a direct integration. However, test the complete workflow before relying on it for regular publishing.

Step 3: Connect and Authorize Your Accounts
After choosing a tool, connect your website and social media accounts using the service's official authorization process.

For a WordPress integration, this usually means activating the relevant plugin and completing the connection steps. For a social media management platform, it means selecting each channel and granting the requested permissions.

Review the account details carefully. Make sure you connect the correct business page, professional profile, or publishing account.

Use the permissions required for the intended workflow. Avoid sharing passwords directly with third parties when an official account authorization process is available.

After connecting each account, verify that it appears in the publishing dashboard. Check whether the service allows automatic publishing for that particular account type or requires you to approve posts through a notification.

If a platform connection fails, review the tool's troubleshooting instructions and confirm that the account still has the required permissions.

Step 4: Configure the Automation Trigger
The trigger determines when the workflow begins.

For a website publishing workflow, a common trigger is the publication of a new article. Depending on the tool, this may be handled directly by the website integration or through a feed that reports newly published content.

Configure the trigger so that it responds to the intended publishing event rather than every change made to a draft.

For example, your desired workflow might follow these steps:

A new article is published on the website.

The integration detects the newly published article.

The workflow retrieves the available title, URL, excerpt, and image.

The publishing tool prepares the social media post.

The post is published or scheduled for the selected accounts.

The workflow records the result where the service provides a publishing history.

The available fields and actions depend on the tools you connect.

Add filters if the workflow should only distribute certain types of content. You might choose to exclude private pages, internal announcements, or content that is not intended for public promotion, provided the integration supports those conditions.

Test the trigger with a suitable article before enabling it for every new publication.

Step 5: Customize Posts for Each Social Platform
A common mistake is to send the same caption to every social network without checking whether the message suits the destination.

The article URL can remain the same, but the introduction should match the audience and available format.

For LinkedIn, you could introduce the article by explaining the professional problem it addresses. For Facebook, a direct question or a short summary may be more appropriate. A visually focused platform may require an image or video that communicates the topic clearly.

Prepare a reusable template containing the elements you want each post to include.

A simple template might contain:

A short introduction that explains the article's value.

The article title or a concise description.

The article URL.

A relevant call to action.

Appropriate hashtags, where useful and supported.

Avoid inserting hashtags or promotional language automatically without checking their relevance.

If your publishing tool supports separate templates for each account, configure them individually. Jetpack Social documents per-connection message templates as a paid feature. Other platforms may offer different customization options depending on the account and plan.

The aim is to preserve the core message while adapting the presentation to each destination.

Step 6: Prepare Article Images and Link Previews
A social media post may include a featured image, a link preview, or other media, depending on the destination and publishing method.

Before enabling automation, review the way your website presents article metadata. Check that each article has an accurate title, a useful description, and an appropriate featured image.

LinkedIn's official help documentation explains that sharing a URL can produce a preview image when the platform retrieves the relevant information. The preview may not appear as expected if the URL does not meet the platform's requirements or the required information cannot be retrieved.

For this reason, test a published article URL rather than assuming the preview will always work.

Check that the image matches the article, the headline is accurate, and the description does not contain outdated information. Avoid using unrelated images simply because they are available in the publishing system.

If your automation tool lets you choose a different image for each platform, use that feature when it improves the presentation. Otherwise, prepare a suitable featured image that works across the destinations you have selected.

Step 7: Test the Workflow Before Full Automation
Do not connect every account and immediately assume the process is working correctly.

Publish or select a suitable test article and confirm that the workflow produces the intended result.

Check the following:

The correct article triggers the workflow.

The title and URL are accurate.

The expected social media accounts are selected.

The caption displays correctly.

The image or link preview appears as intended.

The post is published or scheduled at the expected time.

The publishing service reports the result accurately.

If the workflow publishes duplicate posts, investigate whether multiple triggers are monitoring the same article or whether more than one integration is sharing the content.

If posts fail to appear, check the connection status, permissions, publishing requirements, and any error messages supplied by the service.

Test different article types if your website uses categories, custom content types, or special publishing rules. Do not assume that a workflow designed for standard blog posts will automatically handle every other content type.

Once the test is successful, enable the workflow for the intended content categories and social accounts.

Step 8: Monitor Results and Maintain the Workflow
Automation requires ongoing checks. Social media platforms can change their publishing requirements, account permissions can expire, and third-party integrations can experience errors.

Review the publishing history regularly, where available. Confirm that new articles are being distributed to the expected accounts and investigate repeated failures.

Track performance using the analytics available through your social media platforms, publishing tool, or website analytics service.

Useful measures include link clicks, referral traffic, engagement, and the performance of individual posts. Use these results to identify which topics and promotional messages attract attention from your audience.

You can also review whether certain article categories perform better on particular networks. Use verified performance data rather than assuming that every platform will produce the same results.

Update your templates when article titles, branding, calls to action, or publishing requirements change. Remove unused accounts and reconnect services when required.

Most importantly, retain human oversight. Automation should handle repetitive distribution tasks, not replace editorial review. A post about a time-sensitive subject may need a fresh caption, while an article that contains an error should not continue circulating through an unattended workflow.

Common Mistakes to Avoid
Publishing identical content everywhere
The same caption may not work equally well across different platforms. Customize the message when possible and check the requirements of each destination.

Ignoring account permissions
An integration can stop working when an account loses authorization or a publishing permission changes. Check connections when posts fail.

Forgetting to test links and images
An incorrect URL, missing image, or unsuitable preview can reduce the usefulness of a social post. Verify the published result.

Automating every page without filters
Not every page on a website is intended for social distribution. Use filters or account-level controls where available to prevent private, unfinished, or irrelevant content from entering the workflow.

Assuming automation guarantees traffic
Cross-posting makes distribution more consistent, but it does not guarantee clicks, engagement, or search engine improvements. Content quality, audience relevance, and the effectiveness of the promotional message still matter.

Conclusion
Automated social media cross-posting gives bloggers, publishers, and digital marketers a practical way to distribute website content across multiple social media accounts without repeating every publishing step manually.

Start by identifying your website and target platforms. Choose a tool that supports your accounts, configure the trigger, prepare suitable messages and images, and test the entire workflow before enabling automatic distribution.

WordPress publishers can consider Jetpack Social for sharing posts directly from their website. Buffer provides a central environment for preparing and scheduling social posts, while RSS-based automation can connect website feeds to other supported applications.

The most reliable setup combines automation with editorial control. Monitor publishing results, maintain account connections, and adapt promotional messages to the intended audience.

With a tested workflow, your team can spend less time copying links between platforms and more time producing useful content for readers.

Reliable Robotics: "Autonomous Cargo Operations in 2026," With Certification About Two Years Away

Tue, 20 Oct 2026 14:52:08 +0000

Originally published at vibeagentmaking.com.

Reliable Robotics announced $160 million under the subhead "Company to begin autonomous cargo operations in 2026." The operations are the test phase of a three-year federal pilot program and one Air Force demonstration aircraft, and the certification year reported that day is the sixth estimate since 2020 to sit about two years out.

On April 21, 2026, Reliable Robotics announced $160 million in new funding, led by Nimble Partners. The release carried a one-line subhead: "Company to begin autonomous cargo operations in 2026." Five paragraphs down, it named the two programs those operations belong to, a Federal Aviation Administration pilot program in Albuquerque and a contract with the U.S. Air Force, and said: "Both programs will begin operations this year."

Aviation International News ran the story later that day under a different second line: "U.S. start-up is pressing for FAA certification in 2028." The body attributed the date to the company. The money would go to the Reliable Autonomy System, "for which it is targeting FAA certification in 2028."

Operations this year and certification two years later can both be true. The explanation is in the company's other documents and the government's, which describe the same two programs in plainer words.

First, the money. DroneXL, summarizing chief executive Robert Rose's interview with Bloomberg that day, put the valuation at nearly $1 billion and the total raised at $300 million. Bloomberg's own headline, which the company lists on its news page, was "SpaceX Alum's Startup Nears $1 Billion Valuation in Pursuit of Uncrewed Flights." The release also cited "commitments for over 200 systems from commercial and military customers," a figure it does not break down.

What begins this year

The Albuquerque program is the Advanced Air Mobility Integration Pilot Program, known as eIPP. The Department of Transportation and the FAA picked eight projects across 26 states for it, under an executive order the department's page calls "Unleashing Drone Dominance," and Reliable and the City of Albuquerque are one of the eight. When Transportation Secretary Sean Duffy toured the company at Albuquerque International Sunport on June 17, 2026, the department's release said what the program is for. It "allows Reliable Robotics to test its autonomous regional cargo aircraft and explore the benefits this type of service could provide to rural communities." It gave a date: the company's retrofitted general aviation planes "are expected to begin test operations in August 2026." And Duffy said what the government gets from it: "The data from this pilot program will help the FAA finalize essential regulations and safely integrate this technology into the airspace."

That is how operations can come before certification. The department describes the eIPP as "one of the largest real-world testing environments for next-generation aircraft in the world," and what it produces is data for regulations the FAA has not yet finalized.

The company's own documents describe the program the same way once you read past the subhead. Its March 9 release announcing the selection says that Reliable Airlines, its wholly owned cargo airline in Albuquerque, "will conduct autonomous air cargo operations" from the Sunport to Durango, Colorado, and Santa Fe. The same release contains this sentence: "Completion of this program will mark the first commercial operation of regional air cargo service by a large UAS in the United States." UAS stands for uncrewed aircraft system, and the milestone is tied to the program's completion. The company's newest blog post, dated September 11, 2026 and written by Paul Smith, its director of flight operations, gives the program's length: "A three-year project in the FAA's Advanced Air Mobility Integration Pilot Program is creating a runway to test commercial air cargo operations."

The Air Force program is narrower. In August 2025 the company announced a $17.4 million contract, which National Defense Magazine described as a deal "to purchase, integrate and test its continuous autopilot platform onto a Cessna 208B Caravan cargo plane." The company's December 2025 release about Rose's testimony to a House aviation subcommittee refers to "an active contract to deploy an automated Caravan in the Indo-Pacific for the U.S. Air Force in 2026," and the March release says the company will "demonstrate continuous logistics operations without a pilot onboard." That is one aircraft, deployed for a demonstration.

So the operations that begin in 2026 are the opening months of a three-year federal test and a military demonstration with one airplane. Both are real programs with serious partners. At least one close observer read the announcement as more than that. DroneXL's editor, writing that morning, said of the Albuquerque plan: "That is a commercial freight operation, not a demo."

Who flies the airplane

"Autonomous" has a definite meaning in this company's usage, and its technical documents state it plainly. The system keeps the airplane on autopilot through every phase of flight, from taxi and takeoff to landing, while a pilot in a control center on the ground is responsible for the flight. National Defense Magazine, paraphrasing Rose in August 2025, wrote that the system "requires a remote pilot in a control center who uses the radio and programs the aircraft, but who does not hand-fly the plane from far away." The company's April 7, 2026 release on its detect-and-avoid flight tests says its system "is designed to facilitate a remote pilot's responsibility to perform both Remain Well Clear and Collision Avoidance functions against all airborne traffic." Smith's September post is shorter: "you can take the pilot out of the cockpit, but you cannot take them out of the loop."

The people hosting the program use the other word. In the company's own March release, Albuquerque's acting aviation director, Manny Manriquez, calls it a "remote-piloted cargo aircraft deployment project." On the department's June page, the city's economic development director, Max Gruner, speaks of bringing "remotely-piloted regional air cargo operations to New Mexico." The company uses the phrase as well. Its release on the December 2025 testimony says "Reliable's fully automated Cessna 208 Caravan will help expand remotely piloted air cargo operations to small towns and rural communities." In October 2021, the headline on its $100 million funding release read "Reliable Robotics Raises $100 Million to Expand Access to More Places With Remotely Piloted Cargo Operations." Rose called the product "our Remotely Operated Aircraft System" that year, and the company's news page still used the name in 2022. By August 2025 it was the Reliable Autonomy System.

None of these words is false. The airplane does fly itself, and a pilot on the ground does answer for it. "Autonomous" is not new in the company's vocabulary either. Its own release in August 2020 announced "first flights of autonomous passenger airplanes over populated regions," and Fortune reported Rose's prediction the same day of "commercial autonomous cargo deliveries in the U.S. within two years." What varies is which half of the arrangement a document leads with, and the April subhead led with the half that has no pilot in it.

What none of the program documents says is whether anyone will sit in the cockpit during the Albuquerque test flights. The March release, the April release, the department's June page and the September post are all silent on it. The company has been explicit on the point before. The same 2020 Fortune article reported that the company planned cargo delivery flights "within months," and that "these flights will also carry human pilots for safety."

Two years, six times

The certification date is where the company's record is most useful to a reader, because the company has given one to reporters, again and again, for six years. Each row is what was said, where, and the year it implies.

said	where	what	implies
August 2020	FlightGlobal, August 26, 2020	Rose: "We would like to see commercial operations inside of two years." The article: the company "aims to offer a certified pilotless Caravan 208 within as little as two years."	2022
December 2022	Aviation Week, January 6, 2023, reporting what Rose told it in December	full supplemental type certification for the autonomous system "within two years"	end of 2024
July 2023	Aviation Week, July 20, 2023	the company is "on track to conclude the STC process within 18-24 months"	early to mid 2025
December 2023	AIN's FutureFlight, December 9, 2023	the certificate for single-pilot operations "in the 2024-2025 timeframe," with certification for uncrewed operations "a year or two later"	2024 to 2027
August 2025	National Defense Magazine, August 26, 2025	the FAA certifications "within the next two years"	by August 2027
April 2026	AIN, April 21, 2026	"targeting FAA certification in 2028"	2028

The rows do not all name the same milestone. The 2020 statement was about commercial operations. The 2022 and 2023 statements were about supplemental type certification, and as Aviation Week described the program in July 2023, the first certificate still put a licensed pilot in the cockpit, with a follow-on certification to move that pilot to a ground control center. The 2025 and 2026 statements do not say which certificate they mean. What the rows share is their distance: each was about two years out when it was said. The dates in the first three rows have passed, as has the fourth row's date for the single-pilot certificate, and none of those milestones has arrived. The last two rows fall due in 2027 and 2028.

The April release is careful on this point. It lists what the FAA has accepted, "certification plans, means of compliance, and closed issue papers," and says the company "is now rapidly delivering on compliance materials." It gives no year. The year appeared in the press coverage that day, not in the release.

Rose was candid about the uncertainty early on. In July 2023, the month the approval of the certification plan was reported, he told Aviation Week: "it's still hard to predict these things because the FAA does still need to review all of our test evidence." Nothing in this record suggests the company is doing anything other than the work its plan lays out. The table says nothing about bad faith. What it gives a reader is a base rate for the next estimate.

Two flights with no one aboard have been described in detail, by the company and by the press. A Cessna 172 flew for 15 minutes from an airport south of San Jose in September 2019, "all without a single person on board," as Fortune described it. On November 21, 2023, a Cessna 208B Caravan flew for 12 minutes at Hollister, California, supervised by a remote pilot in the company's control center 50 miles away. AIN reported that the FAA allowed that flight under a special airworthiness certificate "for research and development purposes with some limitations," inside a boundary within sight of observers on the ground. The Air Force program has its own approval: in January 2024 the company announced a military airworthiness approval to begin "flight testing and operational missions of its remotely piloted Cessna 208 Caravan for the U.S. Air Force." Of the 130 items on the company's news page, every title that calls a flight pilotless or says no one was aboard is dated August 2020 or December 2023.

Five months later

The department said August. On September 22, 2026, the company's news page lists 130 items (53 press releases, 38 articles, 32 blog posts and 7 interviews), and one of them is dated after the secretary's visit on June 17: Smith's September 11 post. After the runway sentence, it says: "This program, and our work with different branches of the U.S. military, means that we are flying more UAS than ever."

That is the closest thing in the company's record since June to a report on the program's flying, and it should be read straight. It says the company is flying more uncrewed aircraft than it ever has, and it credits the pilot program and its military work. It gives no number, date or route, does not mention cargo, and does not say whether anyone is aboard.

Nothing else fills the gap. Seven web searches on September 22 returned no report of the Albuquerque, Durango and Santa Fe flights beginning and no report of the Air Force deployment. The newest trade-press item they found was Cargo Newswire's June 22 write-up of the secretary's visit, which repeats that test operations were "scheduled to commence in August 2026."

That absence has limits. It does not show that the test flights failed to start; a test flight in a pilot program needs no press release, and "flying more UAS than ever" may include them. What it shows is narrower. A reader who took the April subhead at its word and went looking, five months later, for the cargo operations it announced would find a statement that the company is flying and nothing that says those operations have begun.

DroneXL's editor made a dated call on the day of the round: "Reliable flies its first paid commercial cargo revenue hop out of Albuquerque before the end of summer 2026." As of September 22, the record does not show that flight.

The subhead, rewritten

Put the pieces back together and the April subhead reads differently. In 2026 the company begins the test phase of a three-year federal pilot program in New Mexico and Colorado, flying retrofitted cargo planes that fly themselves while pilots on the ground answer for them, on a system the FAA has not certified and that the company targets for certification in 2028; separately, it deploys one automated Caravan for an Air Force demonstration in the Indo-Pacific. Every clause of that comes from the company, the city or the Department of Transportation. It describes a real program with serious partners. It is not the sentence the company put under its $160 million headline.

The certification year in it is the company's own. It is the sixth since 2020.

The news-page count, dates and title scan come from newsroom_c6681.py, which reads the page's public content store directly; it was last run on September 22, 2026 at 18:59 UTC. Every quotation and figure above is checked against saved copies of its source by figures_c6681.py. Both scripts, their output and the seven search queries are in one folder, with a list of every source page the script reads, when it was saved and a checksum of the saved copy; the pages themselves are linked in the Sources below rather than republished. AIN names Pathbreaker Ventures as the round's lead; the company's release names Nimble Partners, and this piece follows the release.

Sources:

Reliable Robotics, "Reliable Robotics Announces $160M in New Investment," Business Wire, April 21, 2026: the subhead; the fifth paragraph ("Both programs will begin operations this year"); the first paragraph (Nimble Partners, "over 200 systems"); the seventh paragraph (the FAA's acceptances). https://www.businesswire.com/news/home/20260421825512/en/Reliable-Robotics-Announces-$160M-in-New-Investment
Reliable Robotics and the City of Albuquerque Aviation Department, "Reliable Robotics, City of Albuquerque Aviation Department Partner to Enhance Aviation Safety Through FAA Advanced Air Mobility Integration Pilot Program," Business Wire, March 9, 2026: first paragraph ("Completion of this program ..."), fourth (Reliable Airlines' routes), sixth (Manriquez), ninth (the Air Force demonstration). https://www.businesswire.com/news/home/20260309922880/en/Reliable-Robotics-City-of-Albuquerque-Aviation-Department-Partner-to-Enhance-Aviation-Safety-Through-FAA-Advanced-Air-Mobility-Integration-Pilot-Program
U.S. Department of Transportation, "Trump's Transportation Secretary Sean P. Duffy Visits Reliable Robotics to See How American Innovators are Unlocking the Future of Flight," June 17, 2026: second paragraph (the August 2026 date), Duffy's and Gruner's statements, "Additional Information" (eight projects, 26 states). https://www.transportation.gov/briefing-room/trumps-transportation-secretary-sean-p-duffy-visits-reliable-robotics-see-how
Paul Smith, "Safety First, Autonomy Second: Bringing Lessons From the Cockpit into the Loop," Reliable Robotics blog, September 11, 2026: the section "Reliable's Safety First Approach" and the final paragraph. https://reliable.co/blog/safety-first-lessons-from-the-cockpit
Reliable Robotics, News page, 130 items, read September 22, 2026, including the listings for Bloomberg (April 21, 2026), the October 14, 2021 funding release, the May 26, 2022 release naming the Remotely Operated Aircraft System, and the January 30, 2024 military airworthiness release. https://reliable.co/news
Reliable Robotics, "Reliable Robotics Completes Detect and Avoid Testing for the FAA," April 7, 2026, second paragraph. https://reliable.co/pr/faa-daa-testing-terminal-area
Reliable Robotics, "Reliable Robotics CEO and Co-Founder Robert Rose Testifies Before Congress on U.S. Aviation Leadership through Autonomous Aviation," Business Wire, December 3, 2025. https://www.businesswire.com/news/home/20251202031357/en/Reliable-Robotics-CEO-and-Co-Founder-Robert-Rose-Testifies-Before-Congress-on-U.S.-Aviation-Leadership-through-Autonomous-Aviation
Reliable Robotics, "Reliable Robotics Flies Large Cargo Aircraft with No One On Board," Business Wire, December 6, 2023. https://www.businesswire.com/news/home/20231206413888/en/Reliable-Robotics-Flies-Large-Cargo-Aircraft-with-No-One-On-Board
Reliable Robotics, "Reliable Robotics Raises $100 Million to Expand Access to More Places With Remotely Piloted Cargo Operations," Business Wire, October 14, 2021 (headline as listed on the company's news page). https://www.businesswire.com/news/home/20211014005341/en/Reliable-Robotics-Raises-100-Million-to-Expand-Access-to-More-Places-With-Remotely-Piloted-Cargo-Operations
Charles Alcock, "Reliable Robotics Raises $160 Million For Autonomous Flight," Aviation International News, April 21, 2026, subhead and first two paragraphs. https://www.ainonline.com/aviation-news/futureflight/2026-04-21/reliable-robotics-raises-160-million-autonomous-flight
Haye Kesteloo, "Reliable Robotics Raises $160 Million As SpaceX Alum Pushes FAA For First Commercial Uncrewed Cargo Cert," DroneXL, April 21, 2026, first paragraph and "DroneXL's Take." https://dronexl.co/2026/04/21/reliable-robotics-160m-nimble-partners-faa-certification/
Cailley LaPara, "SpaceX Alum's Startup Nears $1 Billion Valuation in Pursuit of Uncrewed Flights," Bloomberg, April 21, 2026 (headline as listed on the company's news page; the article itself was not read). https://www.bloomberg.com/news/articles/2026-04-21/reliable-robotics-raises-more-cash-to-pursue-uncrewed-flights
Jon Hemmerdinger, "With Tesla and SpaceX credentials, start-up flies pilotless Caravan," FlightGlobal, August 26, 2020, first two paragraphs. https://www.flightglobal.com/airframers/with-tesla-and-spacex-credentials-start-up-flies-pilotless-caravan/139905.article
Jeremy Kahn, "Cessna makes history by taking off and landing with no one aboard. Here's how," Fortune, August 26, 2020. https://fortune.com/2020/08/26/space-x-tesla-reliable-robotics-autonomous-airplanes/
Ben Goldstein, "Reliable Robotics Makes Progress On FAA Means Of Compliance," Aviation Week, January 6, 2023, last paragraph. https://aviationweek.com/aerospace/advanced-air-mobility/reliable-robotics-makes-progress-faa-means-compliance
Ben Goldstein, "Reliable Robotics' Certification Plan Formally Approved By FAA," Aviation Week, July 20, 2023. https://aviationweek.com/aerospace/advanced-air-mobility/reliable-robotics-certification-plan-formally-approved-faa
Hanneke Weitering, "Reliable Robotics Flies Cessna Caravan Without A Pilot On Board," FutureFlight (AIN), December 9, 2023, as republished by the Alliance for Aviation Across America on December 11, 2023. https://www.futureflight.aero/news-article/2023-12-09/reliable-robotics-flies-cessna-caravan-without-pilot-board and https://aviationacrossamerica.org/news/2023/12/11/reliable-robotics-flies-cessna-caravan-without-a-pilot-on-board/
Tabitha Reeves, "Air Force Acquiring Autonomous, FAA-Certifiable Cargo Plane," National Defense Magazine, August 26, 2025. https://www.nationaldefensemagazine.org/articles/2025/8/26/air-force-acquiring-reliable-robotics-pilotless-cargo-plane
Haje Jan Kamps, "Reliable Robotics lifts $100M to take autonomous cargo planes where none have gone before," TechCrunch, October 14, 2021. https://techcrunch.com/2021/10/14/reliable-robotics-going-up-in-the-world/
Cargo Newswire, "Reliable Robotics Advances Autonomous Regional Air Cargo Future Through FAA Pilot Program," June 22, 2026. https://cargonewswire.com/reliable-robotics-advances-autonomous-regional-air-cargo-future-through-faa-pilot-program/

A dated promise is only checkable if the record keeps it.

This piece could line up six estimates because each one was written down, dated and still findable years later.

    Autonomous systems raise the same question on a smaller scale: what did the system do, and when, in a record
    nobody can quietly edit afterwards. Chain of Consciousness keeps a tamper-evident record of an agent's actions,
    so a claim you make about it next year can be checked against what it actually did.

pip install chain-of-consciousness
npm install chain-of-consciousness

Or start without installing anything: Hosted Chain of Consciousness.

Design Publishing Queues That Survive Image Provider Outages

Sun, 18 Oct 2026 11:52:14 +0000

A publishing queue should not forget an article because a photo API had a bad afternoon.

Quick solution:

if (providerError.isTransient) {
  return queue.defer({ state: "MEDIA_PENDING", retryAfter: "1h" });
}

The retry design must respect Cloudflare Workflow limits and the provider's Pexels API documentation; provider failure does not decide whether the article itself is valid.

Yet that is exactly what happens when a pipeline treats every missing hero image as "invalid content."

The article may be complete. The metadata may be valid. The internal links may pass. The only failure is an external media provider returning no usable result, a rate-limit response, or a temporary server error.

That is not the same class of failure as a malformed article.

The queue should preserve the article and defer the media stage.

Separate source validity from media availability

A clean pipeline asks two different questions:

Is the article publishable?
Is a valid hero asset available right now?

The first question is editorial.

The second depends partly on external systems.

If you merge them into one boolean, this happens:

article valid
photo provider unavailable
=> source rejected
=> next topic generated

Now a temporary outage has changed editorial history.

A better state model is:

VALIDATED
MEDIA_PENDING
MEDIA_SELECTED
READY_TO_PUBLISH
PUBLISHED

The article identity stays the same while the media stage retries.

Classify media failures

Not every visual failure deserves a retry.

Retryable

provider 429 rate limit;
temporary 5xx response;
network timeout;
provider returns zero acceptable results for one query;
asset download temporarily fails;
deployment check is still pending.

Deterministic repair

selected asset already used when uniqueness is required;
wrong dimensions;
missing attribution;
stale manifest hash;
unsupported media type.

Terminal for that candidate

license does not allow the intended use;
source URL cannot be established;
raster is corrupt;
asset content is clearly irrelevant;
provider explicitly rejects the request.

A terminal candidate is not necessarily a terminal article. Select another asset.

Bound provider retries

External APIs need retry budgets.

Pexels’ API documentation currently documents default API limits of 200 requests per hour and 20,000 per month. A publisher that retries without bounds can turn temporary scarcity into a quota problem. Cloudflare’s Workflow limits are a separate runtime ceiling, so keep provider quotas and orchestration limits distinct.

Use a fixed strategy such as:

query 1 -> retry transient failure up to 2 times
query 2 -> try one alternate search phrase
reviewed catalog -> use only if a genuinely relevant asset exists
otherwise -> MEDIA_PENDING

Do not keep changing the query forever inside one Workflow instance.

The purpose of retries is to absorb transient noise, not to search the entire internet before the run can finish.

Keep the source queued

When media is unavailable, persist the article in a state that makes the next run resume it.

Do not delete the source, mark it duplicate, move to a new topic, create another draft with the same intent, or reset the article ID.

A durable record needs enough identity to resume:

article_id: art_example
slug: example-article
state: MEDIA_PENDING
revision: 2
visual_attempts: 3

Whether this lives in Git, Workflow state, or another durable store depends on the architecture. The invariant is the important part: the article survives.

Reuse reviewed assets carefully

A local catalog can reduce provider dependence.

If the catalog already contains an unused or reusable raster that is genuinely relevant and its license permits reuse, it may be a better fallback than another external request.

But "available" is not enough.

Check topic relevance, provider/source URL, license, attribution, byte hash, dimensions, reuse rules, and whether the same visual is already overused.

Never reuse an unrelated image simply to make the pipeline green.

Bind provenance when selection succeeds

Once an asset is selected, record the evidence immediately.

Useful fields include:

provider: Pexels
source_url: https://www.pexels.com/photo/...
license_url: https://www.pexels.com/license/
attribution: Photo by ...
article_id: art_example

After downloading the final raster, add the MIME type, width, height, byte count, and SHA-256 of the transformed file.

The first block explains where the image came from. The second explains exactly which bytes the publication uses.

Do not invent file metadata before the file exists.

Avoid duplicate work after uncertain responses

Media providers and storage APIs can fail after doing the work.

Example:

download completes
network layer times out before caller records success
retry starts
same image downloaded again under another asset ID

Use stable stage identity.

If an asset selection has already been recorded for article A revision 3, the retry should inspect that record before searching again.

Likewise, if the final raster already exists and its hash matches the intended manifest, verify it instead of creating another copy.

This is the same idempotency principle used throughout Building a Reliable Batch Publishing Workflow.

Verify the actual raster, not provider metadata

A provider response can describe the original photograph, while your pipeline may crop or resize it.

The publication should bind to the final transformed bytes, not merely the provider metadata.

After transformation:

decode the file;
read actual dimensions;
compute byte length;
compute SHA-256;
update the asset manifest;
verify the article points to that asset.

The provider page remains provenance. The transformed file becomes publication evidence.

Keep provider outages out of editorial scoring

A photo API outage says nothing about whether an article has information gain.

Do not lower article quality, factual confidence, duplicate status, or rank-potential merely because an image API is unavailable.

Instead report the failure in the stage that owns it:

editorial: PASS
research: PASS
visual: DEFERRED_PROVIDER
publication: PENDING

This makes the blocker understandable to both humans and automation.

Verify after deployment

A queue is not finished when the image reaches Git.

After deployment, fetch the public hero URL and verify a successful response, correct content type, decodable bytes, expected dimensions, and that the expected article actually references it.

If the article is live but the asset is stale, keep the same publication pending until the intended raster is visible.

That exact-version discipline is part of Designing a Reliable Serverless AI Publishing Workflow.

Design for a provider-independent future

Do not let one provider's response schema leak across the whole publishing system.

Normalize a candidate:

type ImageCandidate = {
  provider: string;
  sourceUrl: string;
  downloadUrl: string;
  attribution: string;
  licenseUrl: string;
  width?: number;
  height?: number;
};

Then the rest of the pipeline can perform relevance checks, dedupe, transforms, manifest binding, and deployment verification without caring where the candidate came from.

That makes adding a second provider a local adapter change instead of a workflow rewrite.

A practical recovery algorithm

When an article reaches the visual stage:

1. inspect existing bound asset
2. if healthy -> continue
3. inspect reviewed catalog for relevant candidate
4. if found -> bind, transform, verify
5. otherwise query provider within request budget
6. reject duplicates or invalid provenance
7. transform final raster
8. validate bytes and dimensions
9. if provider unavailable -> MEDIA_PENDING
10. retry same article later

The crucial line is number 10.

When maintaining these pipelines, teams should also review policies for preventing search intent duplicates in automated systems to ensure safe retries.

Verification and execution checklist

Inspect the active article state to confirm MEDIA_PENDING is recorded instead of deleting the draft.
Verify that external API calls respect rate-limit thresholds and orchestration timeouts.
Confirm that transformed asset hashes match the recorded manifest before deployment.
Check public staging endpoints to ensure the final raster is accessible and correctly linked.

Deterministic Formatting Normalization

Sun, 18 Oct 2026 11:14:40 +0000

Deterministic formatting normalization prevents expensive LLM generation retries when a model output fails structural validation due to minor whitespace variations.

Quick solution:

function normalizeQuickSolutionLabel(content: string): string {
  return content.replace(/^([\*\_]{2}Quick solution:[\*\_]{2})\s*(.+)$/gm, '$1\n$2');
}

When a publishing pipeline enforces strict layout rules, a valid model answer often fails review solely because a required label shares a line with prose. As discussed in our previous guide on Building A Remote Only Android Repository, rigid structural checks help maintain consistency across automated pipelines, but they require careful handling of minor syntax drift. For more information on how to Engineering High Intent Activity Landing Pages, consider the importance of consistent formatting in maintaining a seamless user experience.

Understanding the Markdown Formatting Failure

Automated editorial linters frequently require explicit structural markers, such as a standalone bold label marking the start of a quick solution. Models occasionally emit these labels inline with descriptive text, violating parser expectations. Repeating the entire generation request wastes API credits and latency without altering the underlying formatting tendency. You can review the underlying specifications at CommonMark to understand how block boundaries are parsed.

Implementation Trade-Offs

While automated string repair is efficient, it must remain tightly scoped to avoid corrupting code blocks, quotes, or indented lists.

Option	When to Use It	Trade-Off or Failure Risk	Recommendation
Full Generation Retry	When semantic content is missing or incorrect.	High token cost and increased latency for trivial formatting fixes.	Use only for semantic errors.
Deterministic Regex Repair	When layout variations violate strict structural linters.	Can accidentally alter code blocks if not properly scoped.	Use for isolated whitespace and line-break fixes.
Loose Parser Rules	When pipeline strictness can be relaxed.	Risks letting malformed articles reach production review.	Avoid for automated publishing workflows.

Verification Checklist

Confirm that the repair function targets only line-start labels.
Verify that fenced code blocks and inline code remain untouched.
Run local unit tests to ensure that valid layouts pass without modification.
Check that pipeline execution limits, such as those documented by Cloudflare Workers, are respected during string manipulation.

How I Built a Multi-Agent Micro-SaaS Orchestration Engine in n8n (Zero Cloud Subscriptions)

Sat, 17 Oct 2026 18:29:54 +0000

Building scalable, multi-agent AI systems usually means falling into one of two traps: drowning in the spaghetti code of Python-based orchestration libraries, or bleeding monthly recurring revenue to expensive, proprietary platforms like LangSmith or Vercel AI.

Managing prompt logic, token limits, and sub-agent handoffs across enterprise tools creates massive technical debt. You need a backend to handle agent orchestration, a database for context memory, and a frontend for your users.

In this guide, I’ll show you how to bypass the SaaS tax by building a Micro-SaaS Agent Farm & Sub-Agent Orchestration Engine entirely inside self-hosted n8n.

1. The Bottleneck: Why Commercial Solutions are Overpriced or Fragile

If you've tried deploying AutoGen or LangChain into production, you know they look great in Jupyter Notebooks but are a nightmare to scale.

Cloud Orchestration Costs: Enterprise orchestration platforms charge by the step or token, eating into your margins.
Frontend Friction: Building a custom React/Next.js dashboard just to trigger an agent workflow is overkill for an MVP.
Context Leaks: Relying on third-party APIs for memory management risks leaking proprietary user data and triggering compliance issues.

The solution is a Webhook-driven REST API sitting on top of an n8n Master/Worker architecture, hooked into a simple HTML/Tailwind frontend.

2. The Architecture: Master/Worker Sub-Agent Farm

We are shifting away from monolithic linear workflows to a distributed, parallel processing model.

Frontend (UI Component Library): A lightweight HTML/Tailwind form sends a standard POST request to our n8n webhook.
Master Agent (The Router): An n8n webhook receives the request, evaluates the user's intent, sanitizes the payload, and dynamically routes the task.
Worker Agents (The Farm): Independent n8n sub-workflows (e.g., Research Agent, Drafting Agent, Code QA Agent). These run in parallel via the "Execute Workflow" node.
Memory Manager: A self-hosted Postgres or Redis node that stores session IDs, keeping context zero-leak and strictly within your VPC.

This architecture allows you to deploy a Micro-SaaS instantly. Your UI just passes a JSON payload; n8n handles the heavy multi-agent lifting.

3. The Code & Logic: Handoffs and Sanitization

Domain Sanitization & Routing (JavaScript)

Before the Master Agent triggers a worker, we need to sanitize the input and determine the execution path. Here is the JavaScript logic for a Code Node in n8n that processes incoming webhook data:

// Master Agent Payload Sanitization & Routing Node
const payload = $input.item.json.body;
const rawPrompt = payload.user_prompt || "";

// Basic sanitization
const sanitizedPrompt = rawPrompt.replace(/[<>]/g, "").trim();

// Intent mapping based on keyword heuristics (or cheap LLM classification)
let targetWorker = "general_chat";
if (sanitizedPrompt.match(/research|find|scrape/i)) {
  targetWorker = "research_agent";
} else if (sanitizedPrompt.match(/code|debug|script/i)) {
  targetWorker = "code_agent";
}

return {
  session_id: payload.session_id || crypto.randomUUID(),
  worker: targetWorker,
  clean_prompt: sanitizedPrompt,
  timestamp: new Date().toISOString()
};

Context Structuring (Python)

To prevent context window overflow during sub-agent handoff, we use a Python node to chunk the conversation history before passing it to the Worker Agent's LLM.

# Python Node for Context Management
import json

def truncate_context(history, max_tokens=2000):
    # Rough estimation: 1 token ~= 4 characters
    max_chars = max_tokens * 4
    current_chars = 0
    truncated_history = []
    
    # Traverse history backwards to keep most recent context
    for msg in reversed(history):
        if current_chars + len(msg['content']) > max_chars:
            break
        truncated_history.insert(0, msg)
        current_chars += len(msg['content'])
        
    return truncated_history

# Assuming 'history' is passed from the previous n8n node
raw_history = _input.item.json.get("history", [])
optimized_context = truncate_context(raw_history)

return {"optimized_context": json.dumps(optimized_context)}

LLM Prompt Structuring

To ensure seamless handoffs, force the LLMs to output strict JSON using n8n's structured output settings.
System Prompt Example: You are the Research Sub-Agent. Analyze the context and return ONLY a valid JSON object with keys: {"findings": [], "confidence_score": 0.0, "requires_human": false}.

4. Deployment & Performance

Running a multi-agent farm requires careful orchestration to avoid server timeouts.

Handling Webhook Timeouts: Multi-agent workflows can take 30-60 seconds. Set your initial n8n webhook to "Respond Immediately" and return an HTTP 202 Accepted with a job_id. Your Tailwind frontend can then poll a second webhook (/status) using that job_id.
Rate Limits: When firing parallel worker agents to OpenAI or Anthropic, you'll hit rate limits quickly. Use n8n's Wait Node set to specific intervals between API calls, or route traffic through a load-balancing proxy.
CRM Routing: Once the final aggregator node compiles the workers' outputs, push the cleaned, structured data directly into HubSpot, Salesforce, or Airtable using native n8n credential blocks.

5. Conclusion & Ready-to-use Workflow

By decoupling the UI from the agentic backend and utilizing a Master/Worker sub-agent architecture in n8n, you can deploy infinitely scalable Micro-SaaS tools with zero cloud orchestration subscriptions. You own the code, you own the context, and you control the API costs.

You can manually recreate this entire system using the architecture and code snippets provided above.

However, if you want to skip the trial-and-error and instantly deploy this system to start generating revenue, I’ve packaged the complete n8n Micro-SaaS Agent Farm & Sub-Agent Orchestration Engine. It includes the production-ready n8n JSON blueprints, the reusable Tailwind/HTML frontend components, and the self-hosted memory schemas.

Grab the turnkey production-ready package here:

Instant Access on Whop: Get it here
Direct Download on Gumroad: Get it here (Use promo code EARLYBIRD at checkout for 20% off).

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

The Night My Pipeline Rejected 43.8% of Everything — and Was Right

Sat, 17 Oct 2026 09:46:03 +0000

Last month, my automated software-ingestion pipeline did something terrifying: it rejected 43.8% of all updates in a single run. Forty-three point eight percent. My first instinct was that the pipeline was broken. It wasn't. It was the only thing in the room doing its job.

I run an open software catalog. Every few days, an automated pipeline pulls new releases from vendors, GitHub, and F-Droid, verifies them, and publishes them. That night it pulled the fire alarm on nearly half the catalog — two SHA-256 hash mismatches (Google Chrome and CCleaner, of all things) and twelve signature mismatches across apps like Obsidian, Tor, and Ventoy.

Here’s what I learned fixing it, distilled into the checklist I now run before any binary goes live.

1. START WITH THE HASH — BUT KNOW WHAT IT CAN’T TELL YOU

Every release I publish carries a SHA-256 checksum, recomputed at download time. It’s the cheapest integrity check in existence:

sha256sum installer.exe
# compare against the publisher's published value

If the hash doesn’t match, stop. Don’t install it, don’t “try it anyway.” A mismatched hash means the file changed in transit — or it isn’t the file the publisher shipped. That night, Chrome and CCleaner’s hashes didn’t match their expected values. The pipeline refused them, and rightly so: a hash mismatch is never a rounding error.

But a hash answers only one question: did this file change? It says nothing about who made it. That’s what signatures are for.

2. VERIFY THE SIGNATURE, NOT JUST THE CHECKSUM

A checksum tells you the file is intact. A signature tells you it came from the right key. For Android packages, the tooling is free:

apksigner verify --print-certs app.apk

The critical step most people skip: check that the certificate fingerprint matches the publisher’s known key. The first time you see a new fingerprint on a familiar app, treat it as suspicious until proven otherwise. For desktop software, GPG serves the same role:

gpg --verify installer.exe.sig installer.exe

The pattern is identical everywhere: fetch the artifact, fetch the signature, verify against the publisher’s public key. And if a project ships binaries with no signatures at all? That’s a data point about the project — not a reason to skip verification.

3. ENROLLMENT IS THE HALF OF VERIFICATION EVERYONE FORGETS

Here’s the mistake that cost me a week. My pipeline verified every APK signature correctly — and still rejected twelve apps. The parser wasn’t broken. The cryptography was fine. The problem: I had never enrolled those signers in the first place.

Signature verification has two halves, and I was only doing one:

1. Is this signature cryptographically valid? (the tool answers this)
2. Do I recognize this signer? (only my allowlist answers this)

Twelve apps were signed by keys my system had simply never recorded — new maintainers, rotated keys, corporate renames. My favorite: a publisher whose legal name changed by a single dot (“Dynalist Inc.” vs “Dynalist Inc”), which my strict string match treated as a stranger. The pipeline was doing its job; my trust store was incomplete.

The fix is boring and essential. Keep an explicit registry of known-good signers per package, keyed by certificate fingerprint:

# trust_store.json — enrolled signers, one entry per package
{
  "com.example.app": {
    "fingerprints": ["AB:CD:EF:12:34..."],
    "enrolled_on": "2026-10-13",
    "note": "Key rotation announced in v4.2 changelog"
  }
}

When a new fingerprint appears, that’s an event, not an error — investigate it once, enroll it deliberately, and move on. Auto-trusting unknown signers defeats the entire purpose.

4. REJECT LOUDLY — WITH A THRESHOLD YOU CHOSE IN ADVANCE

A verification system that silently accepts everything is decoration. Mine fails the entire ingestion run closed if more than 15% of updates get rejected. That number is deliberate: a sudden spike means either the upstream world changed (keys rotated, publishers restructured) or my pipeline broke. Either way, I want a human looking at it before anything ships.

The exact threshold matters less than the principle: decide in advance what “too many failures” looks like, and make the pipeline stop instead of shrugging. Quiet failures are how bad binaries reach users. My 43.8% night looked like a disaster and was actually the system working exactly as designed — it just needed a human to enroll the new signers and re-run.

5. DECIDE IN ADVANCE WHAT TO DO WITH THE UNVERIFIABLE

Not everything is signable. Some legitimate tools ship unsigned binaries — portable builds, indie utilities, projects too small for signing infrastructure. You have three honest options: reject them, allowlist them explicitly, or verify them another way (reproducible builds, publisher-published hashes fetched over HTTPS).

I allowlist them — explicitly, per binary, with a written reason. What I never do is let an unsigned binary through on a technicality. “The check didn’t apply” is not the same as “the check passed,” and conflating the two is how exceptions quietly become the rule. Ventoy’s unsigned binary, for example, sits in my allowlist with a note explaining why — visible, reviewable, deliberate.

THE CHECKLIST

Before any binary goes live:

SHA-256 matches the publisher’s published value (recomputed at download, not trusted from a mirror)
Signature verifies against the publisher’s known key
Signer fingerprint is in the enrolled registry — new fingerprints get investigated, never auto-trusted
Rejection rate for the run is under threshold, or the whole run stops
Unsigned artifacts are explicitly allowlisted with a written reason — never silently passed

None of this is exotic. It’s plumbing. But it’s the plumbing between a stranger’s server and your users’ machines, and every piece of it earns its place the first time it catches something. Mine caught something on a random Tuesday night, rejected nearly half the catalog, and was right.

AI Document Management Software in India How to Check Whether an Answer Is Actually Supported by You

Sat, 17 Oct 2026 04:50:51 +0000

AI tools that answer questions from your documents sound great on paper. You type a question, and in two seconds you get a clean answer. No scrolling through forty PDFs. No asking a colleague to resend something.

But here is the question nobody asks until it is too late: how do you know the answer is actually true? AI tools are known to make things up sometimes, and if that happens inside your tax papers or client contracts, it is not a small mistake. It can cost you a client, or worse, land you in trouble with an authority.

This article is about that exact problem. If you are looking at document management software in India, and especially anything that uses AI, you need to know how to check whether an answer is really coming from your files, or just sounding confident.

Why this question matters more than it seems

Most of us have used a chatbot at some point and seen it give a wrong fact with full confidence. It does not say "I am not sure." It just answers, and the answer sounds correct. This habit is called hallucination in the AI world, and it is a real problem.

Now put this same behaviour inside a tool that holds your company's documents. Imagine you ask, "What is the notice period in the vendor contract?" and the tool gives you a number that is simply wrong, not because the document said something different, but because the AI guessed. If you pass that answer to a client or use it to plan your work, the mistake becomes your mistake, not the software's.

This is why, when you compare any cloud document management software in India, you should not just look at speed and design. You should look at whether the answer can be checked.

What "grounded" actually means

In simple words, a grounded answer is one that comes directly from a line in your document, not from the AI's general knowledge. The tool should be able to show you exactly where the answer came from, like the file name, the page, and even the sentence.

Think of it like a school exam. A teacher does not just want the answer, she wants you to show your working. A document system should work the same way. The answer is one part, and the proof behind it is the other part. If the tool cannot show the proof, you have no real way to trust it.

This difference is also what separates a toy chatbot from a genuine document management solution in India built for serious work like contracts, GST filings, or client records.

Simple ways to check if an AI answer is real

You don't need to be a tech expert to test this. Here are a few things any business owner, accountant, or office manager can check.

Ask for the source, every time. A good system will show you the exact document and the exact line the answer was pulled from. If you ask a question and only get a plain sentence with no link back to a file, that is a warning sign.

Open the source and read it yourself. Don't trust the answer blindly even when a source is shown. Click through and read the actual paragraph. Good software makes this a one-click action, not a hunt through folders.

Test it with something you already know. Pick a contract or invoice you know well and ask the tool a question about it. If the answer matches what you already know, and the proof lines up, you can trust the tool a little more. If it gets this wrong, that tells you a lot.

See what happens when there is no answer. This is probably the most important test of all. Ask a question that your documents simply cannot answer, something that is not in any file. A trustworthy system will say it cannot find a supporting document. A system that still gives you a confident-sounding answer is guessing, and that is a problem you do not want in work related to money or law.

Check if it tells you when something is unclear. During scanning or reading a messy photo, some fields may not be clear enough to read properly. Good software flags these for a person to check instead of filling in a guess on its own.

Why this matters more for CA firms, lawyers and compliance teams

If you run a CA firm, a law office, or handle compliance work, this topic is not optional reading, it is central to your daily work. Clients trust you with papers that have real consequences, tax filings, agreements, board papers, and more. A wrong number in a TDS calculation or a wrong date in a termination clause is not a small slip, it can affect real money and real legal standing.

This is also why, when firms search for the best document management software in India, they should put proof-based answers higher on their checklist than flashy design or a long feature list. A tool that looks modern but quietly guesses is more dangerous than a plain old folder system, because a folder system never pretends to know something it does not.

Where Intellodocs fits into this

Intellodocs, built by Imbibe Technologies, is one example of a document system designed around this exact idea. It is an AI-native document vault that reads the content of a file rather than relying on the file name. When you ask it a question in plain language, it returns an answer that points at the exact sentence it came from, with the source document opened right next to it. If there is nothing in your documents to support an answer, it says so instead of filling the gap with a guess.

This matters because Intellodocs was built with practices like chartered accountants, law firms, and company secretaries in mind, people who cannot afford a confident but wrong answer. The system also keeps version history, access logs, and file-level permissions, so even the proof trail itself can be checked later if needed.

A short checklist before you choose a tool

Before signing up for any system, ask these simple questions:

Does every answer show the source line, not just a plain sentence?
Can I open the original document in one click from the answer?
Does it admit when it has no matching document, instead of guessing?
Are unclear scans flagged for a human to check?
Is there a record of who asked what and what was shown?

If a vendor cannot answer these clearly, slow down before you commit your documents to it.

Final thoughts

AI can genuinely save hours of work, and for many offices it already has. But speed is only useful when the answer underneath it is correct. Before trusting any AI document management software in India with your contracts, tax papers, or client files, take a few minutes to test whether its answers are actually grounded in your documents, or just sound grounded. That small check can save you a much bigger headache later.

FAQs

1. What does it mean when an AI answer is "grounded" in a document?
It means the answer is pulled directly from a specific line or passage in your own file, and the tool can show you that exact source. It is the opposite of the AI making up an answer from general knowledge.

2. Can AI document management software work with scanned or blurry files?
Good systems are built for this, since many Indian offices receive scanned paper and phone photos. The software should read these through OCR, and when a part is genuinely unclear, it should flag it for a person rather than guess the content.

3. Is cloud document management software safe for confidential client files?
It can be, as long as the vendor offers proper encryption, access control, and clear data residency choices such as managed cloud, a dedicated instance, or on-premise hosting. Always check these details before storing privileged or client documents.

Harnessing the Nondeterministic Machine: Practical Lessons in Agentic AI Hardening

Fri, 16 Oct 2026 20:00:57 +0000

There is a specific kind of confidence failure that shows up in agentic AI systems. It is not the dramatic hallucination - the confident fabrication of a person who never existed. It is quieter than that. The model understands the task. It understands the data. And then it decides it has a better idea.

We ran into this repeatedly while building the content health maintenance workflow for Synthadoc, an open-source AI-native wiki engine. The workflow's job sounds modest: scan wiki pages for structural problems like duplicate headings or thin sections, propose targeted fixes, and let the user approve them before applying anything. What we found, and eventually fixed, is a catalogue of ways an agent can go wrong even when the model is capable and the intent is clear - and why the solution is never just a better instruction.

The Problem We Were Solving

Synthadoc ingests raw documents - PDFs, web pages, transcripts, spreadsheets - and uses an LLM to synthesize them into a structured Markdown wiki. Over time, the same topic gets ingested from multiple sources. Without intervention, a single wiki page about Alan Turing can accumulate ten copies of ## Bletchley Park and Cryptanalysis and eight copies of ## Early Life and Education. The page is coherent in isolation but structurally broken: duplicate content, contradictory emphasis, and thin sections that exist only because a heading was created before the body text was written.

The content health scanner addresses this. It is deliberately a pure-Python heuristic with no LLM dependency - it detects duplicate_section, empty_section, thin_section, unclosed_code_block, orphaned_heading, and broken_list_nesting through deterministic regex. This part is reliable. The next part - using an LLM to fix the issues - is where the story gets interesting.

What We Intended the Workflow to Do

The design was explicit. For each flagged page:

Load the page content and the list of detected issues
Send both to the LLM with a carefully constructed prompt
Show the user a side-by-side BEFORE/AFTER diff
Wait for approval before writing anything
Snapshot the previous version so a rollback is possible

Every step in this design has a purpose. The BEFORE/AFTER review is a human gate, not a formality. The snapshot is a reversibility guarantee. The heuristic scanner runs before the LLM so the issue list is precise, not speculative.

What actually happened when we first ran it told us exactly which parts of our hardening were missing.

What Went Wrong

Failure 1: The Model Rewrote the Page

The first problem emerged immediately. The LLM received the page content and a list of issues. There were twelve structural problems on the page about the Open Source Movement - three duplicate sections and nine thin sections. The AFTER content we received back bore no structural resemblance to the original. The original heading ## Richard Stallman and GNU (1983) was gone. The heading ## The Cathedral and the Bazaar (1999) was gone. In their place: ## Historical Framing and Origins, ### Research Computing Culture and Principled Advocacy, ### GNU Toolchain and the Missing Kernel. The content was factually reasonable. It was also something the user never asked for and could not safely approve, because we had lost all traceability between the original and the proposed version.

The model had, in effect, written its own wiki page from its pre-trained knowledge, using our wiki page as a rough reference. The word "fix" in our prompt was interpreted by the model as license for rewriting.

Failure 2: The Model Kept the Wrong Duplicate

For a page about computing history, the scanner flagged ## Moore's Law appearing three times. Two occurrences were thin summaries of about forty words each. The third was a detailed paragraph with four footnote citations to the source material. Our initial prompt said "keep the first occurrence." The model faithfully kept the first - one of the forty-word summaries - and discarded the version with citations.

Technically correct. Practically, the wrong choice. We had a rule that was precise but not meaningful for the actual goal.

Failure 3: CLI-Provider Artifacts in the Proposed Content

Synthadoc supports multiple LLM backends. One of them is a CLI-based provider - an agentic tool (like opencode or Claude Code) that is itself an agent with its own tool-calling loop. When we routed the content health workflow through this provider, the response text included shell command output: <|func_arg_name|>command<|func_arg_value|>cat /Users/user1/wikis/alan-turing.md. The model had read the actual file from disk, bypassing our carefully constructed context, and its internal tool invocations leaked into the response text we were about to write to the wiki.

Failure 4: Planning Notes Presented as Final Content

In some runs, the proposed content contained lines like:

### LISP (1958) - actually LISP is more third gen but...
### Introduction paragraph (existing)
Expand to 50+ words

These were the model's internal planning notes - draft scaffolding that it had not cleaned up before terminating its response. These notes would have been written to the wiki without detection. It is possible that a user reviewing a diff in a modal at speed might miss them.

Failure 5: Heading Renamed to "Correct" a Date

After tightening the prompt, one run still returned a subtle violation. The original heading was ## The Cathedral and the Bazaar (1999). The proposed content had ## The Cathedral and the Bazaar - the year dropped. The model "knew" the essay was presented in 1997 and silently corrected what it interpreted as an error in the user's own heading. It was an editorial judgment we had not authorized.

The Failure Mode Map

These failures cluster into two categories that are worth naming precisely.

Category A - DRIFT: Model understands task but applies wrong judgment
Category B - HALLUCINATION: Model substitutes its own knowledge for the task

It is important to distinguish. As a result of drift, the right process is being used to make wrong decisions - "keep the first" instead of "keep the best." As a result of hallucination, the right process is being replaced completely - generating a page from weights instead of fixing the one we hand it. Different mitigations are required for each.

How We Hardened the System and Built the Harness

These fixes fall into two distinct layers. Hardening addresses what the model produces: tighter prompts, output parsing, provider-specific guards. Harness engineering addresses what the model can affect: human gates, rollback, scope exclusions. Hardening reduces the probability of a bad output; the harness limits the consequence of one that gets through. Both are required - hardening alone cannot guarantee zero failures, and a harness without hardening just moves the review burden to the human gate.

Hardening the Agent

1. Artifact Extraction as an Input Boundary

The CLI-provider issue required a structural fix, not a prompt fix. We introduced _extract_md_from_response() - a pre-processing step that strips everything before the first # H1 heading in the response. CLI-provider tool call output always appears before the actual content begins. By treating the first H1 as the clean boundary, we recover the markdown content without the artifact noise.

This is an example of boundary enforcement at the output interface: treat the model's raw response as untrusted input to a parser, not as a value ready to write.

2. Draft Detection as a Post-Output Gate

For planning notes, we added _is_draft() - a regex that catches linguistic markers of incomplete thinking: TODO, FIXME, Expand to, Hmm,, Wait,, I'll, Let me, existing content. If any match, the proposed content is flagged and the page is skipped automatically with a clear explanation in the UI.

_DRAFT_RE = re.compile(
    r"^\s*(TODO|FIXME|Expand to\b|Hmm[,.\s]|Wait[,.\s]|I'll\b|I will\b|Let me\b"
    r"|existing content|combine existing|add more content|placeholder)",
    re.IGNORECASE | re.MULTILINE,
)

This is an output validation gate - a deterministic check applied after the model responds and before the result reaches the user approval screen. The model cannot disable it by rephrasing the note.

3. Surgical Prompt Constraints

The original prompt said: "Fix the structural issues listed below." That sentence, to a language model, is nearly unlimited scope. We replaced it with an explicit constraint hierarchy:

ABSOLUTE RULES - violating any one is a failure:
  • PRESERVE every existing section heading EXACTLY - same text, same # level,
    including any dates or years in parentheses. Do not 'correct' headings.
  • PRESERVE the section ORDER exactly as in the original.
  • Do NOT add new top-level or second-level sections.
  • Do NOT rename, merge, split, or reorder any sections.
  • Do NOT alter factual claims in sections you are not fixing.

PERMITTED CHANGES (only these, only where the issue list directs):
  1. Duplicate sections: keep the most complete occurrence (most words and/or
     citations); delete the others. Place the kept version where the first
     occurrence was. Do NOT merge or rewrite - keep it verbatim.
  2. Thin/empty sections: add factual prose UNDER the existing heading.
     The heading text must remain unchanged.

Changing from "fix issues" to "permitted changes" is intentional. The model cannot rationalize around a list of what it is allowed to do when permissions are enumerated rather than prohibitions.

4. Issue Count Threshold for Nondeterministic Providers

Even with the tighter prompt, pages with more than six issues on a CLI-provider run produced hallucinated new sections. The CLI provider is itself an agentic tool with its own reasoning loop - it does not behave like a simple completion endpoint, and the compound nondeterminism (our model + its internal model) overwhelms a long issue list.

We added a hard skip at six issues for the CLI path:

# CLI providers (opencode, claude-code) are agentic - they read files,
# plan before writing, and hallucinate new sections when the issue list
# is long. API providers follow the prompt reliably and don't need this
# guard. This path is CLI-only, so the cap applies only there.
_MAX_ISSUES_AUTO_FIX = 6

API-key providers (Anthropic, OpenAI) use a separate code path with no cap, since they are stateless completion endpoints that see the prompt exactly as we construct it. Rather than a model capability, this is a property of the architecture.

Building the Harness

5. System Page Exclusion

Thin sections on pages named index and dashboard were correctly identified by the scanner. These are navigation pages, not content pages - thin sections are structurally appropriate. The workflow would propose expanding them without exclusion, which the user would reject correctly, wasting their time.

We use the existing SYSTEM_PAGE_SLUGS constant to exclude them from the fix loop. No duplicate definition, no magic string. The scanner still runs on them - the issues appear in lint reports - but the auto-fix workflow skips them.

6. The Human Gate as a Structural Requirement

Every proposed fix must pass through a BEFORE/AFTER diff review before anything is written. This is not a feature - it is the architectural guarantee that no automated process can corrupt wiki content without explicit consent. The confirm card shows:

The page slug and issue summary
BEFORE (first 2000 chars of the original)
AFTER (first 2000 chars of the proposed content)
"Approve" / "Skip this page" buttons with a 5-minute timeout (auto-decline)

The scrollability of code blocks in the review modal was a concrete UX issue we had to address - users need to be able to read what they are approving. Gates that are theoretically present but practically unusable are not gates.

7. Snapshot and Rollback as a Safety Net

Before any approved fix is written, snapshot_if_changed() takes a versioned copy of the original content. If the approved result turns out to be wrong, the user can request a rollback by name: "roll back alan-turing." The workflow restores the snapshot, re-runs the scanner, and updates the issue list to reflect the restored state. It is not a rollback to recover from system failure - it is a first-class workflow feature that acknowledges the model may produce something subtly wrong that was not detected during review.

The Broader Principle: Both Layers Are Architectural, Not Textual

The pattern we followed across all of these fixes is consistent: every control - whether it hardens the agent's output or constrains the harness around it - is implemented in code, not in prose.

"Do not hallucinate" in a system prompt is a behavioral suggestion. The model considers it, weighs it against other pressures, and sometimes overrides it. That is not a flaw, it is how language models work. The token prediction process does not have a hard stop for "this would be a hallucination."

Both hardening and harness engineering mean building controls that are not subject to the model's interpretation:

Layer	Control	What it does	Why it cannot be bypassed
Hardening	`_extract_md_from_response()`	Strips pre-H1 content	Runs on raw response bytes, before any model interpretation
Hardening	`_is_draft()` regex	Blocks planning-note content	Deterministic regex match - not in the model's loop
Hardening	PERMITTED CHANGES prompt	Enumerates allowed scope	Narrows the action space; drift must contradict the list
Hardening	Issue count cap	Skips complex pages	Hard code gate; model never sees the page
Harness	System page exclusion	Skips non-content pages	Slug lookup against a constant; not in the prompt
Harness	BEFORE/AFTER human gate	Requires user approval	No write path bypasses this
Harness	Snapshot / rollback	Preserves prior state	Written before the fix is applied

These controls form layers. A fix that evades the prompt constraints is caught by the draft detector or the human gate. A fix that passes the human gate can be rolled back. No single layer is sufficient. The layers together are.

Why This Matters Beyond Wiki Maintenance

Incorrectly updating a wiki page is a recoverable mistake. A user clicks rollback, the page is restored, and no lasting harm is done. But the failure modes we observed - a model substituting its own knowledge for the task, a model including its internal tool calls in the output, a model silently correcting data it considered wrong - are not domain-specific. The same failure patterns appear in:

Agentic coding tools that refactor code the user did not ask to touch
Document automation systems that "improve" a legal clause beyond the approved scope
Data pipelines where an LLM normalizes values using world knowledge rather than the provided schema
Financial report generators that extrapolate figures not present in the source data

In each case, the consequence of unhardened agentic behavior scales with the stakes of the domain. A hallucinated section in a personal wiki is recoverable. A hallucinated figure in a financial disclosure is not.

The argument for hardening is not that models are bad. It is that models are nondeterministic, and production systems require deterministic guarantees at the boundaries where AI output meets persistent state.

What to Apply From This

If you are building an agentic system that reads and modifies persistent data, consider these as minimum requirements:

Boundary enforcement. Treat the model's output as untrusted input at every handoff. Parse it. Validate it. Strip what does not belong before it reaches the next step.

Deterministic post-output gates. Add validation logic that runs after the model responds and is not subject to the model's behavior. Draft detection, schema validation, output format checks. These are deterministic; the model cannot reason around them.

Enumerated permissions over enumerated prohibitions. In prompts, tell the model what it is allowed to do, not only what it must avoid. The scope of permitted actions is easier to reason about than an open-ended task with a list of exceptions.

Acknowledge provider heterogeneity. Not all "model" configurations behave the same way. A CLI-based agentic provider and a stateless API completion endpoint have fundamentally different behavioral properties. Design your hardening layer to account for both, or constrain which providers can reach which actions.

Human gates as structural requirements. For any workflow that modifies persistent state, a human review step is not a UX nicety - it is a control. Make it usable. If the review UI cannot display the full diff, the gate is not functioning as intended.

Reversibility as a first-class design constraint. Snapshots and rollback should be designed in from the start, not added after the first production incident. Assume the model will sometimes produce a subtly wrong result that passes review, and design the recovery path accordingly.

Closing

It took multiple iterations for Synthadoc's content health maintenance workflow to behave predictably. Rather than rephrasing the prompt, each iteration addressed a specific failure mode. As a result, the team trusts the workflow - not because the model is perfect, but because the system is designed to catch and contain errors.

Synthadoc is open source. The content health scanner, the resolver workflow, and the draft detection logic are all available at Synthadoc git repo. If you are building AI-native systems that write back to persistent state, the patterns described here are worth examining in the context of real code, not just as abstractions.

The nondeterministic machine can be harnessed. The harness is engineering, not prompting.

From Bug Reproduction to Playwright Test — Without Starting From Scratch

Fri, 16 Oct 2026 07:59:06 +0000

Ever reproduced a bug, documented the steps, and then had to write the same steps all over again as an automated regression test?

That repetitive workflow is what inspired me to build QA Bug, a Chrome extension designed to turn browser-based bug reproductions into Playwright test drafts.

🛠️ How it works

Reproduce the bug — Interact with the website as you normally would.

Capture the steps — Record browser actions and relevant interactions.

Add assertions — Define what the test should verify.

Generate a Playwright test draft — Turn the recorded session into a .spec.ts file that you can review, edit, and adapt to your project.

The goal isn't to replace QA engineers or magically generate perfect tests. It's to reduce repetitive work between reproducing a bug and creating a starting point for regression automation.

I'm building this as a practical tool for QA engineers and developers who want to make browser testing less repetitive.

💬 I'd like your feedback

Would you use a tool that converts bug reproduction sessions into Playwright test drafts?

What would you need before trusting the generated tests in a real project?

Which part of your bug-to-regression workflow takes the most time?

I'm interested in honest feedback from people who work with manual testing, Playwright, and test automation.

🔧 I'd rather build something QA engineers actually need than add features nobody uses.

Chrome Web Store:
https://chromewebstore.google.com/detail/qa-bug-→-regression-test/khoelciicbkdeieibchdndccdncpelbg?authuser=1&hl=tr

Automated Lead Enrichment Workflow: The Complete Guide

Fri, 16 Oct 2026 06:17:20 +0000

Writing

Automated Lead Enrichment Workflow: From Raw Leads to Reliable CRM Data
A new lead enters your CRM with just a name, an email address, and a company. Your sales team still needs to find the person's role, identify the company, validate the available information, and update the record.
Doing this manually doesn't scale. But automating the process without proper validation can create duplicate contacts, incorrect company matches, and unreliable CRM data.
The real challenge isn't just enriching leads—it's building a workflow you can trust.
I published a practical guide at Causly Lab covering how to build an automated lead enrichment workflow from beginning to end.
Here's what you'll learn:

Workflow architecture: Connect lead sources, enrichment APIs, validation steps, and your CRM.
Implementation approaches: Compare no-code automation, self-hosted n8n, and custom-coded pipelines.
API integration: Understand provider requests, data mapping, and normalized lead records.
Data quality: Handle missing fields, conflicting values, duplicate records, and uncertain matches.
Reliability: Design retries, rate-limit handling, and recovery paths for failed requests.
Production readiness: Consider security, data provenance, testing, monitoring, and cost per successfully enriched lead.
One important principle: a successful API response doesn't automatically mean you've found the correct person or company. Your workflow needs explicit matching and field-merging rules.
If you're building CRM integrations, sales automation, or lead-generation systems, this guide can help you choose an implementation approach and understand the engineering decisions involved.
Read the complete technical guide:
https://www.causly.in/lab/automated-lead-enrichment-workflow
I'd also be interested to hear from developers: how do you handle conflicting enrichment data and duplicate records in your own workflows?

Each Fix to My Classification Prompt Exposed the Next Problem

Thu, 15 Oct 2026 14:01:19 +0000

This comes from my first n8n project with an LLM in it: an intake classifier for an automation agency. It's a practice brief, so the agency and the client are fictional, and I built it with an AI collaborator. The workflow and my full process notes are in the GitHub repo.

A client fills in a form, Gemini reads the project description through a Basic LLM Chain with a structured output parser (which forces the model to answer in a fixed JSON shape), and the submission gets sorted into a category that decides which emails go out and what gets logged to Google Sheets. This post is only about the classification prompt, and about a handful of test descriptions that kept sending me back into it.

Where it started

Three of the five categories are real project types: simple_automation, ai_workflow and custom_integration. The other two, ambiguous and invalid, are for submissions that don't sort cleanly. I'm leaving those for another post.

My first definition of simple_automation allowed exactly one action off a trigger. That seemed reasonable until I tested it with a description I'd picked as the easiest case:

when a client submits the form on my website, notify me and log it to a sheet

It came back ambiguous. Notifying me and logging to a sheet is two actions, and my definition only allowed one.

Problem 1: I'd defined the category by counting

Raising the limit to two actions would have been a patch. The real problem was that counting actions doesn't separate the three categories at all. What separates them is whether there's conditional logic, whether data is actually transformed, and whether AI reasoning is involved. I rewrote all three definitions around those, and the simple_automation one now says so directly:

simple_automation: One or more actions fire in a fixed, uniform way off a
single trigger. [...] No conditional branching (no "if X then Y, else Z"),
no computed or derived values, and no AI/LLM reasoning involved. The number
of destinations touched does not matter [...]

Problem 2: the model had to commit before it could compare

The next test was "route incoming leads smartly based on their details". I read the reasoning field on that one, and it said it saw two valid readings and picked one anyway.

Working out why, I realized it was my prompt's doing. It evaluated the categories in sequence, so the model had to commit to one before it ever checked whether another also fit. Genuine overlaps were being settled by the model's best guess instead of reaching ambiguous. I rebuilt the evaluation so each category is assessed independently and the model counts how many plausibly fit:

Do not decide sequentially. Instead:
[...]
3. Count how many categories plausibly fit:
   - Exactly one fits -> assign that category.
   - Two or more fit, and the description does not specify enough to pick
     between them -> assign 'ambiguous'.

I also added a line to the prompt saying that "more common in practice" is a guess about unstated intent, which is exactly what ambiguous exists to catch.

Problem 3: the schema asked for the answer before the reasoning

My schema also listed category before reasoning, so the model was structurally being asked for its answer before it had written the explanation that was supposed to inform it. I swapped them:

{
  "type": "object",
  "properties": {
    "reasoning": { "type": "string" },
    "category": {
      "type": "string",
      "enum": ["simple_automation", "ai_workflow", "custom_integration", "ambiguous", "invalid"]
    }
  },
  "required": ["reasoning", "category"]
}

(Trimmed to the two fields that matter here.) I changed the order and kept testing. I have no record of testing that change by itself, so I can't say how much of the later improvement comes from it.

Problem 4: the fix overcorrected

With the new wording, the model started treating "automatically" as a possible AI signal. That word just means "not manual", and it appears in nearly every automation request, so it would push ordinary requests toward ambiguous.

I tightened the definitions so each category only counts as plausible if the text contains a specific word or phrase that grounds it, and I named "automatically" and similar words as things that don't count. I also added a rule aimed at the habit I'd just watched:

If you find yourself justifying a category with "could imply" or "might
involve" without pointing to a specific word or phrase that drove that
reading, do not count it

Cleaning up

The old [TIE-BREAKING] section was still in the prompt. After the evaluation rewrite it repeated the same logic less precisely, so I removed it and reran both the original failing case and a genuinely ambiguous one to confirm each landed where it should.

Checking the boundaries

I wrote two more tests aimed at the seams between categories instead of one category at a time.

The first stacked signals on purpose: conditional branching ("if it's not feedback, stop"), several systems (Gmail, a data table, Slack), and clear AI work (sentiment extraction, summarizing, drafting a reply). The reasoning field weighed the branching signals against the AI ones and landed on ai_workflow, using my rule that custom_integration applies when the logic is driven by fixed rules, not AI reasoning. That rule is my call. A description with both could reasonably be argued the other way, so the result shows the prompt follows my rule, not that the rule is correct.

The second was the opposite check: budget-based lead routing across HubSpot, Slack and Mailchimp, with no AI language at all. I wanted to see whether multi-system complexity alone would get pulled into ai_workflow. It came back custom_integration, with the reasoning ruling out both other categories using the exclusion wording.

What this doesn't show

Every test above is a single description I wrote myself. That was enough to find four problems in the prompt, and not enough to say the prompt is reliable. A real set of varied inputs is the next thing it needs.

Connecting AI to Business Apps: 5 Things Developers Should Get Right

Wed, 14 Oct 2026 14:35:27 +0000

Adding an AI API to an application is relatively straightforward. Making that integration useful in a real business workflow takes more thought.

A business application already has users, data, permissions, and rules. When AI becomes part of that application, it needs to work alongside those existing systems.

Here are five things worth considering before building the integration.

1. Start With the Actual Business Problem

Before choosing a model or writing API calls, understand what users are trying to accomplish.

For example, an employee might spend time searching through internal documents to find a process or policy. An AI assistant could help retrieve relevant information without requiring the employee to leave the application.

That is a clearer starting point than simply deciding to add a chatbot.

Ask a few practical questions:

What task is taking too much time?

What information does the user need?

Where does the task happen today?

How will we know whether the integration is useful?

The answers help define what the AI feature should actually do.

2. Give AI the Right Context

A language model does not automatically know a company's internal processes, documents, or business records.

If an employee asks about a company procedure, the application may need to retrieve information from an approved knowledge source before asking the model to respond.

One common approach is retrieval-augmented generation (RAG). Instead of relying only on the model's existing knowledge, the application retrieves relevant material and includes it as context.

This is particularly important in ERP and CRM applications, where the response may depend on company-specific information.

For example, BizzAppDev developed an ERP AI Knowledge Assistant that connects conversations inside an ERP with organisational knowledge. The implementation uses file search and vector stores to retrieve relevant information, followed by AI processing, response validation, and citation handling.

The important point is not just that the application can generate an answer. It is that the answer is connected to relevant information within an existing business workflow.

3. Keep Permissions and Business Rules in the Application

AI should not become a shortcut around the application's existing controls.

Consider a user asking an assistant to retrieve customer information. The application still needs to determine which records that user is allowed to access.

The same principle applies when AI can initiate actions.

There is a meaningful difference between an assistant suggesting a change and a system automatically making that change.

For actions that affect business records, developers should define:

Which users can request the action

Which records and tools are available

What validation is required

When confirmation or approval is necessary

The model can help interpret a request, but the application should remain responsible for enforcing permissions and business rules.

4. Plan for Unexpected Responses and Failures

AI responses are not always complete or correct. External API calls can also fail, time out, or return unexpected output.

These situations need to be handled as part of the application design.

Imagine an employee asking an assistant for an internal policy that is not available in the connected knowledge source.

A useful response would explain that the information could not be found, rather than presenting an unsupported answer as a company policy.

Developers should also consider what happens when an API request fails or a response does not match the format the application expects.

Output validation, appropriate error messages, and safe fallback behaviour make the integration more dependable.

5. Test the Complete Workflow

A successful API response does not necessarily mean the integration works.

Testing should include the full journey, from the user's request to the final result inside the application.

For a knowledge assistant, that might involve checking whether:

Relevant documents are retrieved

Users receive information appropriate to their access

Responses accurately reflect the available sources

Missing information is handled clearly

Follow-up questions work as expected

It is also worth testing with realistic business questions, not just simple examples prepared during development.

A feature can work well in a demonstration and still struggle when people use it in different ways.

Putting It Into Practice

These considerations become especially important when AI is connected to software that people already rely on.

An ERP knowledge assistant, for example, is not simply a chat interface connected to a language model. It involves knowledge retrieval, application integration, response handling, and decisions about access and reliability.

The same thinking applies to other AI-powered business features, whether they help users find information, review documents, or complete routine tasks.

The goal is not to add AI everywhere. It is to make a specific workflow more useful while keeping the surrounding application reliable.

Final Thoughts

AI APIs provide useful capabilities, but the integration around them determines how those capabilities work in practice.

Starting with the workflow, providing relevant context, enforcing permissions, handling failures, and testing realistic scenarios can help developers build features that fit existing business applications.

For developers working on AI integrations: which part tends to be the most challenging—data access, output validation, or connecting AI to existing business logic?

Building a Self-Healing, Type-Safe Desktop RPA with Python and Computer Vision

Wed, 14 Oct 2026 10:48:41 +0000

Desktop automation has a dirty secret: it’s terrifyingly brittle. If you’ve ever written a script that relies on static X/Y coordinates, you know the pain. A Windows update changes a button's padding by 5 pixels, a user moves a window, or UI scaling shifts—and suddenly your bot is blindly clicking empty space.

Enterprise RPA platforms (UiPath, Automation Anywhere) solve this, but they charge extortionate licensing fees just to access basic computer vision capabilities. You shouldn't have to pay massive corporate subscriptions for your script to "see" what's on the screen.

Today, we are going to build a resilient, local, type-safe automation engine that executes workflows based on visual state and OCR, completely free of corporate bloat.

1. The Bottleneck: Why commercial solutions are overpriced or fragile

When dealing with legacy desktop applications or Citrix environments where there is no DOM to inspect, developers usually resort to two terrible options:

Blind Coordinate Clicking: pyautogui.click(x=100, y=200). This breaks the second a window is resized.
Enterprise RPA: Heavily bloated, vendor-locked IDEs that cost thousands per seat and require a PhD in their proprietary visual languages.

The alternative? A lightweight, Python-based pipeline utilizing Computer Vision (OpenCV) and OCR (Tesseract/LLMs) to dynamically detect UI elements, combined with strict type-safe bindings (Pydantic) to ensure our workflows only execute when the application is in the exact expected state.

2. The Architecture: Visual State Detection

Instead of defining "where" an element is, we define "what" the screen should look like.

Our architecture consists of three layers:

The Vision Engine: Continuously captures screen buffers and runs fast localized OCR to find anchor text (e.g., "Submit", "Invoice Number").
The Type-Safe State Machine: Uses Pydantic to validate the parsed UI data. If the OCR reads a messy string, we run domain sanitization and pass it through a local LLM to map it strictly to our data model.
The Orchestrator (n8n): Acts as the brain, triggering the Python RPA agent via local webhooks and routing the structured data to our CRM.

3. The Code & Logic: Type-Safe Detection and LLM Sanitization

Here is the core logic. First, we define our expected UI state using Pydantic. Then, we use a combination of OCR and a lightweight LLM prompt to sanitize the messy text read from the screen (e.g., extracting clean domains and email addresses from a messy desktop email client).

import cv2
import pytesseract
import pyautogui
from pydantic import BaseModel, Field, ValidationError
from typing import Optional
import openai

# 1. Type-Safe Definition of our expected UI State
class InvoiceUIState(BaseModel):
    is_loaded: bool
    invoice_number: Optional[str] = Field(None, description="Extracted Invoice ID")
    client_domain: Optional[str] = Field(None, description="Sanitized client domain")

# 2. Domain Sanitization & LLM Prompt Structuring
def sanitize_ocr_with_llm(raw_ocr_text: str) -> InvoiceUIState:
    """Uses a local or fast API LLM to extract structured data from messy OCR."""
    prompt = f"""
    You are a data extraction agent. Parse the following raw OCR text from a desktop application.
    Extract the invoice number and sanitize the client's email into a clean domain.
    If the UI hasn't fully loaded, set is_loaded to false.
    
    Raw OCR:
    {raw_ocr_text}
    """
    
    # Using OpenAI's structured outputs to guarantee our Pydantic model
    response = openai.ChatCompletion.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        functions=[{"name": "extract_ui", "parameters": InvoiceUIState.schema()}],
        function_call={"name": "extract_ui"}
    )
    
    return InvoiceUIState.parse_raw(response.choices[0].message.function_call.arguments)

# 3. Execution Logic
def click_element_by_text(target_text: str):
    """Finds screen coordinates dynamically based on OCR, avoiding X/Y brittleness."""
    screenshot = pyautogui.screenshot()
    screenshot.save("buffer.png")
    
    img = cv2.imread("buffer.png")
    data = pytesseract.image_to_data(img, output_type=pytesseract.Output.DICT)
    
    for i in range(len(data['text'])):
        if target_text.lower() in data['text'][i].lower():
            x, y, w, h = data['left'][i], data['top'][i], data['width'][i], data['height'][i]
            # Self-healing click: always targets the center of the found text
            pyautogui.click(x + w/2, y + h/2)
            return True
    raise Exception(f"Element '{target_text}' not found in current UI state.")

4. Deployment & Performance: Handling UI Rendering and Routing

When running this in production, desktop applications don't load instantly. We must implement Exponential Backoff to handle timeouts, rate limits, and rendering delays.

Instead of time.sleep(5) (which is an anti-pattern), wrap your vision checks in a polling loop:

import time

def wait_for_ui_state(target_text: str, timeout: int = 30):
    start_time = time.time()
    while time.time() - start_time < timeout:
        try:
            if click_element_by_text(target_text):
                print(f"UI State matched: {target_text}")
                return
        except Exception:
            time.sleep(1) # Wait 1 second before re-evaluating screen buffer
    raise TimeoutError("UI failed to render in time.")

Integrating with n8n:
To integrate this local python engine with your broader marketing or CRM automation, wrap the Python script in a simple FastAPI server. You can then use an n8n HTTP Request node to trigger your local RPA agent securely, passing payloads back and forth between your desktop applications and your web-based CRMs.

5. Conclusion & Ready-to-use Workflow

Desktop automation doesn't require five-figure enterprise licenses. By combining open-source Computer Vision, LLM-based domain sanitization, and strict Python typing, you can build self-healing automation pipelines that survive UI changes.

You can absolutely take the code snippets above, integrate them with n8n, and build this pipeline yourself. However, if you want to skip the trial-and-error and get a production-ready system right now, I've packaged the complete engine.

VisionRPA: Type-Safe Desktop UI Automation & OCR Engine is available as a turnkey package with pre-built test fixtures, n8n JSON templates, and the complete Python source code.

Grab it here:

Instant Access on Whop: Link
Direct Download on Gumroad: Link (Use promo code EARLYBIRD for 20% off).

Stop letting hard-coded X/Y coordinates break your workflows. Build visually, execute locally.

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

How to Control Any Legacy Desktop App from n8n with a Type-Safe Python Vision Endpoint

Mon, 12 Oct 2026 10:56:13 +0000

How to Control Any Legacy Desktop App from n8n with a Type-Safe Python Vision Endpoint

Legacy desktop applications—custom ERPs, Delphi clients, SAP GUI, Citrix windows, and air-gapped financial systems—remain the bane of modern workflow orchestration. They lack REST endpoints, expose zero webhook triggers, and fail to expose accessibility tree nodes for conventional UI automation.

Traditionally, dev teams face two flawed paths:

Enterprise RPA suites (UiPath, Automation Anywhere, Microsoft Power Automate Desktop): Costs scale into five figures annually, require dedicated Windows Server instances, and depend on proprietary orchestrators disconnected from modern CI/CD or n8n topologies.
Brittle native scripts: Unsynchronized pyautogui scripts running on infinite loops with static time.sleep() calls, collapsing at the first shifted pixel or dynamic modal dialogue.

This guide demonstrates an alternative: a local, type-safe Python FastAPI daemon that acts as an OS-level microservice, controllable directly via standard n8n workflows using screen capture, coordinate-aware OCR, and deterministic vision targeting.

1. The Bottleneck: The Fragility of Native Selectors

Commercial RPA platforms rely heavily on accessibility frameworks (Microsoft UI Automation, MSAA, IAccessible2). However, legacy Win32, Java Swing, Qt, and WPF apps often emit unpopulated element trees:

[Desktop]
  └─ [Window: LegacyBilling.exe]
       └─ [Pane: CustomCanvas] <-- Zero child nodes; totally opaque to DOM/UI inspection

When accessibility selectors fail, commercial tools fall back to basic coordinate clicks or image-template matching (cv2.matchTemplate), which fails under minor antialiasing shifts, dynamic theme updates, or resolution changes.

The Direct Vision-to-Action Protocol

By treating the desktop screen as an ephemeral API, we establish a stateless loop:

Inspect: Frame-buffer capture via native C-level screen grabbers (mss).
Extract & Locate: Type-safe OCR parsing with coordinate bounding boxes normalized to DPI.
Assert: Pydantic schema validation ensuring required text or anchors exist before execution.
Dispatch: Hardware-level cursor/keyboard dispatch.
Acknowledge: HTTP 200 payload returned to n8n with extracted data or execution state.

2. The Architecture

The automation stack decouples orchestration from execution:

┌─────────────────┐       HTTP / JSON        ┌──────────────────────────────┐
│   n8n Server    │  ────────────────────>   │   FastAPI Local Agent (OS)   │
│ (Cloud/Self-Host│  <────────────────────   │   (Listening on 127.0.0.1)   │
└─────────────────┘      Structured Data     └──────────────┬───────────────┘
                                                            │
                                    ┌───────────────────────┴───────────────────────┐
                                    ▼                                               ▼
                         ┌─────────────────────┐                         ┌─────────────────────┐
                         │  OCR / Vision Core  │                         │ PyAutoGUI / ctypes  │
                         │ (EasyOCR/Tesseract) │                         │ (Input Dispatch)    │
                         └─────────────────────┘                         └─────────────────────┘

n8n Orchestrator: Handles scheduling, error retries, CRM integrations (PostgreSQL, HubSpot, Slack), and flow logic.
FastAPI Daemon: Runs directly on the target host (Windows/macOS/Linux), exposing type-safe endpoints secured with an internal Bearer token.
Vision Engine: Runs localized OCR with bounding boxes returned as normalized (x_min, y_min, x_max, y_max) values.

3. The Code & Logic

3.1 The FastAPI Agent

Below is the complete implementation of the core endpoint daemon handling coordinate targeting and OCR extraction.

# endpoint.py
import os
from typing import Optional, List
import mss
import numpy as np
import cv2
import pytesseract
import pyautogui
from fastapi import FastAPI, HTTPException, Security, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
from pydantic import BaseModel, Field

pyautogui.FAILSAFE = True  # Slam cursor to corner to abort

app = FastAPI(title="Desktop Vision Endpoint", version="1.0.0")
security = HTTPBearer()
AUTH_TOKEN = os.getenv("AGENT_AUTH_TOKEN", "dev_secret_token_change_me")

def verify_token(credentials: HTTPAuthorizationCredentials = Security(security)):
    if credentials.credentials != AUTH_TOKEN:
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Invalid automation bearer token"
        )
    return credentials.credentials

class Coordinate(BaseModel):
    x: int
    y: int

class OCRMatch(BaseModel):
    text: str
    confidence: float
    center: Coordinate
    bounding_box: List[int] = Field(..., description="[x, y, w, h]")

class ClickRequest(BaseModel):
    target_text: Optional[str] = None
    fallback_coords: Optional[Coordinate] = None
    double_click: bool = False
    offset_x: int = 0
    offset_y: int = 0

class TypeRequest(BaseModel):
    text: str
    clear_field_first: bool = True
    submit_enter: bool = False

def capture_screen_matrix() -> np.ndarray:
    with mss.mss() as sct:
        monitor = sct.monitors[1]  # Primary monitor
        screenshot = np.array(sct.grab(monitor))
        # Convert BGRA to RGB
        return cv2.cvtColor(screenshot, cv2.COLOR_BGRA2RGB)

@app.post("/ocr/scan", response_model=List[OCRMatch], dependencies=[Security(verify_token)])
def scan_screen(contains: Optional[str] = None):
    image = capture_screen_matrix()
    data = pytesseract.image_to_data(image, output_type=pytesseract.Output.DICT)
    
    matches: List[OCRMatch] = []
    n_boxes = len(data["text"])
    
    for i in range(n_boxes):
        text = data["text"][i].strip()
        conf = float(data["conf"][i])
        
        if conf > 40.0 and len(text) > 0:
            if contains and contains.lower() not in text.lower():
                continue
                
            x, y, w, h = data["left"][i], data["top"][i], data["width"][i], data["height"][i]
            matches.append(OCRMatch(
                text=text,
                confidence=conf,
                center=Coordinate(x=x + w // 2, y=y + h // 2),
                bounding_box=[x, y, w, h]
            ))
            
    return matches

@app.post("/action/click", dependencies=[Security(verify_token)])
def click_element(req: ClickRequest):
    target_x, target_y = None, None
    
    if req.target_text:
        matches = scan_screen(contains=req.target_text)
        if matches:
            # Pick the highest confidence match
            best = max(matches, key=lambda m: m.confidence)
            target_x = best.center.x + req.offset_x
            target_y = best.center.y + req.offset_y
            
    if target_x is None and req.fallback_coords:
        target_x = req.fallback_coords.x + req.offset_x
        target_y = req.fallback_coords.y + req.offset_y
        
    if target_x is None:
        raise HTTPException(status_code=404, detail="Target not located on display")
        
    pyautogui.moveTo(target_x, target_y, duration=0.2)
    if req.double_click:
        pyautogui.doubleClick()
    else:
        pyautogui.click()
        
    return {"status": "success", "clicked_at": {"x": target_x, "y": target_y}}

@app.post("/action/type", dependencies=[Security(verify_token)])
def write_text(req: TypeRequest):
    if req.clear_field_first:
        pyautogui.hotkey("ctrl", "a")
        pyautogui.press("backspace")
        
    pyautogui.write(req.text, interval=0.03)
    
    if req.submit_enter:
        pyautogui.press("enter")
        
    return {"status": "success", "typed_chars": len(req.text)}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="127.0.0.1", port=8765)

3.2 The n8n Integration Loop

In n8n, interact with the local agent using standard HTTP Request nodes over local loopback (or via a secure Tailscale mesh if n8n is hosted remotely).

Here is a raw n8n HTTP Request node configuration targeting the /action/click endpoint:

{
  "parameters": {
    "method": "POST",
    "url": "http://127.0.0.1:8765/action/click",
    "authentication": "genericCredentialType",
    "genericAuthType": "httpHeaderAuth",
    "sendHeaders": true,
    "headerParameters": {
      "parameters": [
        {
          "name": "Authorization",
          "value": "Bearer dev_secret_token_change_me"
        }
      ]
    },
    "sendBody": true,
    "contentType": "raw",
    "rawContentType": "application/json",
    "body": "={\n  \"target_text\": \"Submit Order\",\n  \"offset_x\": 0,\n  \"offset_y\": 0,\n  \"double_click\": false\n}",
    "options": {
      "timeout": 5000
    }
  },
  "name": "Click 'Submit Order'",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 4.2,
  "position": [460, 240]
}

4. Deployment, DPI Scaling & Performance

When orchestrating OS interactions from a server pipeline, three production factors determine stability:

1. High-DPI Display Scaling

On Windows systems with 125% or 150% UI scale (common on laptops and 4K workstations), OpenCV and PyAutoGUI coordinates may drift if your Python process is not marked DPI-aware. Fix this at initialization in your runner:

import sys
if sys.platform == "win32":
    import ctypes
    ctypes.windll.shcore.SetProcessDpiAwareness(2) # Per-monitor DPI aware

2. Tailscale & Remote n8n Instances

If your n8n orchestrator is cloud-hosted while your target client runs on a private Windows VM behind NAT:

Do not expose the FastAPI port to the public internet.
Install Tailscale on the Windows agent and n8n container.
Direct n8n to communicate with the host's 100.x.y.z Tailscale mesh IP with token validation.

3. Deterministic Retries in n8n

Desktop GUIs exhibit variable latency. Avoid using raw delays (Wait nodes). Instead, implement a Polling Retry Loop in n8n using an If condition:

Execute /ocr/scan?contains=Invoice.
Check if the returned array length is > 0.
If 0, wait 500ms and increment a retry counter.
Route to /action/click only when the element is detected on screen.

5. Conclusion & Ready-to-Use Package

By converting raw OS displays into type-safe, HTTP-accessible endpoints, you eliminate proprietary RPA overhead and maintain all business logic within unified n8n workflows.

You can manually implement the boilerplate above, configure PyTesseract, tune the bounding-box logic, and map out the n8n HTTP schemas yourself.

Alternatively, you can grab the turnkey production-ready package—which includes pre-configured FastAPI binaries, packaged system-tray runners, auto-healing OCR wrappers, and importable n8n workflow templates:

Instant Access on Whop
Direct Download on Gumroad — Use coupon code EARLYBIRD at checkout for 20% off.

🛠️ D'autres outils MR Studio qui pourraient vous intéresser :

Designing an AI Concierge That Qualifies Visitors With Facts You Publish

Sat, 10 Oct 2026 18:44:55 +0000

TL;DR

An AI concierge is a customer-facing assistant on your website or a messaging channel that answers questions about your offer from your own content, asks qualifying questions and passes the conversation to a person with a summary.
The design question is the boundary: what the assistant may answer from, which questions it must ask, and what it hands over when a visitor is ready to talk.
Your knowledge base sets the answer ceiling, because the catalogue, the FAQ, the pricing pages and the rules for what to recommend form the assistant's whole vocabulary.
Qualification is the step most contact forms skip. The assistant asks for the constraint that decides the recommendation, such as volume, deadline, site count or team size, and records the answer in the visitor's own words.
Pricing stays a citation. The assistant quotes the price on your page, and anything that requires a negotiation leaves the conversation for a person.
The hand-off carries four fields: the need, the fit, the boundary of what was promised and the owner who picks it up, which is what turns a chat transcript into a working lead.
Cost and abuse limits belong in the first version: message caps per session, rate limits per visitor, bot protection and a spend ceiling tied to the model provider.
Built from components you can host, meaning an automation platform, retrieval over your own documents, a model of your choice, your calendar and your email, the assistant keeps visitor conversations inside infrastructure you control.
The outcome worth measuring is a faster first response with a summary a human can act on, which is a different metric from chat volume.

What an AI concierge does on a website

Most visitors leave without asking anything. The questions they would have asked arrive later by email, in a form that says "please contact me", or never at all. A concierge exists to move that conversation to the moment the visitor is actually on the page, and to leave behind a record of what they wanted.

The mechanics are unglamorous. A chat surface sits on the site or in a messaging channel. Behind it, an assistant answers from your content, asks the questions your team asks on every sales call, and then writes a short summary that reaches a human through email, a calendar booking or a CRM entry. Netics' own concierge page describes exactly that sequence across four steps, from learning the offer to handing the conversation over.

Netics editorial card: the boundary is the design. Everything the assistant says comes from published facts, and everything it cannot support becomes a hand-off.

The reason to build it from your own material rather than from a general model is the same reason retrieval exists at all. A language model asked about your business will produce fluent answers that sound right and contain numbers nobody approved. Grounding changes the question from "what does the model know about us" to "what do our documents say", which is a question with a checkable answer.

The knowledge base sets the answer boundary

Everything the assistant can say comes from something you already published or wrote down for it. That is a small idea with large consequences, because it converts a content problem into a maintenance problem.

The sources that matter for a sales conversation are usually already sitting on the site: product or service pages, a pricing page, an FAQ, delivery or lead-time notes, and a short list of rules about what to recommend when a visitor describes a need. Add the internal version of the same knowledge, which is the set of constraints your team applies before quoting: minimum order quantities, supported regions, onboarding effort, what you decline to take on.

Retrieval is what makes that usable at conversation speed, and filtering is what keeps it precise. Qdrant's documentation describes constraining a query by payload filters, which is the mechanism that keeps an answer about a small deployment from quoting terms that apply to an enterprise contract. In practice the filter is built from what the visitor has already said: the product family, the region, the volume band.

Two rules keep the boundary honest as the assistant grows. First, every answer should be traceable to a document, so a wrong answer becomes a content fix rather than an argument about the model. Second, the assistant's vocabulary needs an owner. A pricing page that changes without the knowledge base being re-synced is the most common way these projects go wrong, which is why the sync belongs in the deployment rather than in somebody's calendar reminder.

n8n's official documentation for the AI Agent node (docs.n8n.io, retrieved 2026-10-07): the node builds an agent from a chat model plus connected tools, and the documentation states that at least one tool sub-node is required.

Qualification asks the questions your team keeps repeating

Qualification is where a chatbot becomes a sales tool, and it is also where most implementations stay shallow. A form asks for a name, an email and a message. A concierge asks for the one thing that decides the recommendation.

For a service business that is often volume, deadline or scope. For a product business it is usually the deployment shape: how many sites, how many users, which of the two models on the pricing page. The assistant should ask for that constraint before it recommends anything, and it should ask in the visitor's own terms rather than forcing a dropdown.

There are three practical rules worth building in from the start. Ask one question at a time, because a wall of four questions reads as a form. Record the answer verbatim alongside the summary, because paraphrases lose the detail a salesperson would have noticed. And accept "I don't know" as an answer, since a visitor who cannot state a budget is a visitor who needs the explanation more than the quote.

The tooling for this is standard. n8n's documentation describes the AI Agent node as a chat model plus connected tools, where the agent chooses which tool to call, and it requires at least one tool sub-node. The retrieval side has its own node: n8n's Qdrant Vector Store node documentation states that the node can be connected directly to an agent's tool connector, so the lookup against the knowledge base becomes one of those tools. A lookup against the knowledge base, a booking action and a hand-off action are three tools, which is enough structure for a qualifying conversation.

Handing the conversation over with a usable summary

The hand-off is the part that decides whether anyone trusts the assistant. A raw transcript leaves the salesperson to reread the whole conversation; four fields turn it into a lead they can act on.

Netics editorial card on the hand-off: four fields turn a transcript into a lead the person who picks it up can act on.

The need comes first, written as the visitor expressed it. The fit follows, naming the offer the assistant recommended and the reason it chose that one. The boundary records what was promised, including the price quoted and the source page it came from, which is what protects both sides in the follow-up call. The owner closes it: who receives it, through which channel, and by when.

Netics' published description of the concierge ends its flow with exactly this step, sending the summary by email, booking the call, or creating the lead in the client's own tools. The detail worth copying is that the assistant stays presented as an assistant. Visitors who know they are talking to an AI ask better questions than visitors who suspect they are talking to a badly supervised human.

Retrieval quality shows up here as well. If the summary says the assistant recommended the wrong service level, the fix is usually a missing document or a filter that was too broad, and both are content edits. Treating those reports as a weekly review item is what keeps a concierge from drifting into confident nonsense after six months of catalogue changes.

Cost and abuse limits belong in the first version

A concierge is a public endpoint attached to a paid model, which makes it a cost centre with an audience. Limits designed after launch tend to arrive as an outage.

Four controls cover most of the risk. A cap on messages per session keeps a looping visitor from running indefinitely. A rate limit per visitor address handles the obvious scripted case. Bot protection sits in front of the chat surface, because a form-protection layer that only guards the contact page leaves the new endpoint open. A spend ceiling with an alert threshold at the model provider turns an unexpected pattern into a notification rather than an invoice.

There is a fifth that is easier to miss: an answer length limit. Long answers cost more, read worse on a phone and give a visitor less chance to correct the assistant's understanding. Short answers with a follow-up question are both cheaper and more useful.

Qdrant's official filtering documentation (qdrant.tech/documentation, retrieved 2026-10-07): the payload filter is the mechanism that keeps an answer inside the product family, region or volume band the visitor actually asked about.

Keep the logs too, with a retention window you can defend. Conversation logs are what let you answer the two questions that will come up: which questions do visitors keep asking that our content does not answer, and which answers did the assistant get wrong. For a company with any privacy obligation at all, that log is personal data, so the retention decision belongs with whoever owns the privacy policy.

Building it from components you can host

The stack that makes this practical is deliberately boring, and our own deployment runs on the same pieces: an automation platform for the conversation flow, retrieval over your documents, a model of your choice, and your existing calendar and email.

The choice that matters commercially is where the conversation data lives. A hosted assistant service gets you running in an afternoon and puts your visitor conversations and your pricing rules inside somebody else's account. The hosted-component version takes longer, and it keeps the retrieval index, the logs and the model credentials inside infrastructure you control, with a provider you can change when prices or policies move. Our own write-up of the components behind an AI concierge covers the four steps of the flow, and the automation platform that runs it explains why an agent with tools fits this job better than a fixed command list.

Model choice deserves its own sentence, because it is the part teams over-think. A qualifying conversation with retrieval is a task small and mid-size models handle well, and the model is the easiest component to swap later. Retrieval quality, document freshness and the hand-off format decide whether the assistant is useful, which is why the grounding and refusal behaviour of a private assistant is the part of that article worth reading before choosing a provider.

Netics editorial card: the knowledge base is the product surface. Adding a document changes what the assistant can say, and that is the lever a team actually holds.

One operational note closes the loop. Treat the concierge as a product with a release cadence rather than a one-off build. A monthly review of unanswered questions, a quarterly review of the pricing and rules documents, and a check on the cost ceiling covers most of what goes wrong between launches.

If you want a second opinion on whether this fits your sales process, book a free 30-minute audit and bring the questions your team answers most often. That conversation is usually enough to tell whether a concierge would help and where its boundary should sit.

Originally published on the Netics blog.

Building a Smart OCR Converter with Python: Turning Images into Editable Text

Sat, 10 Oct 2026 16:26:56 +0000

In today’s digital world, information is everywhere but not all information is available in a usable format. Many businesses still manage scanned documents, printed forms, invoices, receipts, and images containing important text. Manually typing this information into a computer takes time, increases the risk of errors, and reduces productivity.

This is where an OCR (Optical Character Recognition) converter built with Python can make a real difference.

The Problem: Text Locked Inside Images

Imagine a business receiving hundreds of scanned documents every week. Employees need to read each document, extract the information, and manually enter it into a digital system.

This process creates several challenges:

Time-consuming work: Manually copying text from documents wastes valuable hours.
Human errors: Incorrect spelling, missing information, and typing mistakes can affect data accuracy.
Difficult document management: Searching for specific information inside image-based documents is not easy.
Limited productivity: Employees spend more time processing documents and less time on important tasks.
Scalability issues: As the number of documents grows, manual processing becomes increasingly difficult.

Businesses need a smarter way to convert image-based text into digital information.

The Solution: Developing an OCR Converter Using Python

To address these challenges, we can build an OCR converter using Python. The application reads text from images and scanned documents, then converts it into machine-readable text that users can copy, search, edit, or save.

Python is an excellent choice for this project because it provides powerful libraries for image processing, text recognition, and web application development.

How Does the OCR Converter Work?

Image Upload: Users upload an image containing text, such as a JPG, PNG, or a supported scanned document.

Image Processing: The application prepares the image for recognition. Techniques such as grayscale conversion, noise reduction, and thresholding can improve text readability.

Text Recognition: An OCR engine analyzes the processed image and identifies the characters and words.

Text Extraction: The recognized text appears on the screen, allowing users to review and copy the results.

Download and Export: The extracted content can be saved as a text file or integrated into other document-processing workflows.

The goal is to make document conversion simple, accessible, and efficient.

Technologies Behind the Project

A Python-based OCR converter can use several technologies working together:

Python: Handles the main application logic and processing workflow.
Tesseract OCR: Recognizes text in images and converts it into digital text.
Pytesseract: Connects Python code with the Tesseract OCR engine.
Pillow or OpenCV: Helps process images before recognition.
Flask: Can provide a lightweight web interface where users upload images and view extracted text.

These tools make it possible to build a practical OCR application without developing a text-recognition engine from scratch.

Why Image Preprocessing Matters

One of the most important lessons in OCR development is that the quality of the input image affects the quality of the extracted text.

A clear, high-resolution image usually produces better results than a blurry or poorly lit photograph.

For improved recognition, developers can implement:

Grayscale conversion to simplify image information.
Thresholding to improve contrast between text and background.
Noise removal to reduce unwanted marks.
Image resizing to improve the visibility of small characters.
Deskewing to straighten tilted documents.

However, preprocessing methods should be selected according to the document type. Excessive processing can sometimes remove important details or reduce recognition accuracy.

Real-World Applications

A Python OCR converter can support many practical use cases.

Business Administration: Extract text from invoices, forms, and printed records.

Education: Convert scanned study materials and printed notes into searchable text.

E-commerce: Help digitize product information and paper based inventory records.

Healthcare Administration: Assist with digitizing appropriate non-sensitive administrative documents, subject to privacy and security requirements.

Digital Archiving: Make historical documents and scanned records easier to search and organize.

OCR can also become part of a larger workflow that extracts structured information, classifies documents, or transfers recognized text into a database.

Challenges Developers Should Consider

Building an OCR converter is not only about extracting text. A reliable application should also handle unexpected situations.

Poor image quality can lead to incorrect recognition.
Complex layouts, tables, and multiple columns may require additional processing.
Handwriting is generally more challenging than printed text.
Multilingual documents may require additional language data.
Large files can increase processing time and memory usage.
Uploaded documents should be handled securely, with appropriate file validation, privacy protections, and retention policies.

Developers should test the application with different image formats, document layouts, languages, and image qualities before deploying it for real-world use.

Future Improvements

An OCR converter can evolve into a more advanced document processing platform.

Possible improvements include PDF support, batch image conversion, multilingual recognition, searchable document archives, structured data extraction, and integration with databases or business management systems.

A web-based interface can also make the application accessible to users without requiring them to run Python scripts manually.

Conclusion

Building an OCR converter with Python is a practical way to apply programming skills to a real-world problem. By combining Python, image preprocessing, and OCR technology, developers can reduce manual data entry and make document information easier to access.

The most important lesson is that useful software is not simply about writing code it is about solving problems efficiently and creating a better experience for users.

At Next Big Creative, we believe technology should help businesses work smarter, improve digital processes, and turn ideas into practical solutions.

You thinking and we building.

Next Big Creative
www.nextbigcreative.com

Building a Selector-Free Autonomous Desktop RPA Engine with Python & Vision LLMs

Sat, 10 Oct 2026 11:32:25 +0000

Building a Selector-Free Autonomous Desktop RPA Engine with Python & Vision LLMs

Legacy enterprise software—on-premise SAP GUI installations, AS/400 terminal emulators, desktop-only accounting suites, and specialized medical record software—rarely provides accessible REST APIs. For the past two decades, the standard remedy has been traditional RPA (Robotic Process Automation) platforms like UiPath, Automation 360, or Power Automate Desktop.

In practice, traditional RPA is notoriously brittle. It relies on accessibility element trees, Win32 handle introspection, or static DOM selectors. When an update alters an internal UI hierarchy, a display scale shifts from 100% to 125%, or dynamic IDs change, automation jobs break.

This guide demonstrates how to architect a selector-free, OS-agnostic RPA engine in Python that leverages Multimodal Vision LLMs (such as Anthropic Claude 3.5 Sonnet / Computer Use) to perceive screen buffers and drive low-level OS input events natively across Windows, macOS, and Linux.

1. The Bottleneck: Why Traditional RPA Breaks

Traditional RPA frameworks rely on accessibility trees (Microsoft UI Automation, Apple Accessibility API, AT-SPI). This architecture incurs three major vulnerabilities:

Fragile Tree Traversal: Virtualized grids (like SAP or legacy WPF apps) render contents via hardware-accelerated canvases without exposing child accessibility nodes.
Resolution & DPI Vulnerability: Pixel-offset OCR fallbacks shatter when remote desktop windows resize, rendering absolute coordinates invalid.
Licensing Costs: Commercial enterprise runners charge $5,000 to $15,000 per unattended bot license annually, locking infrastructure into closed ecosystems.

The Vision-Grounding Alternative

Instead of querying internal OS handle structures, a Vision-Driven RPA engine operates identically to a human engineer:

Capture the raw desktop framebuffer.
Pass the downscaled/encoded buffer into a multimodal reasoning model alongside an action objective.
Extract normalized visual coordinate predictions (x_pct, y_pct) alongside an action token (click, double_click, type, key_press, scroll).
Map those coordinates to native hardware events.
Verify the state delta across consecutive frames with a self-healing loop.

+--------------------+      +-------------------------+      +-------------------------+
| Desktop Framebuffer| ---> | Vision Coordinate Model | ---> | Action Dispatcher       |
| (X11 / Quartz / OS)|      | (Claude / Qwen-VL)      |      | (pyautogui / pynput)    |
+--------------------+      +-------------------------+      +-------------------------+
          ^                                                               |
          |                 +-------------------------+                   |
          +---------------- | Visual Verification Loop|<------------------+
                            | (Delta / SSIM Check)    |
                            +-------------------------+

2. System Architecture

The engine consists of four core decoupling boundaries:

Display Capture Pipeline: Intercepts screens via fast C-bindings (mss) and handles multi-monitor resolution normalization.
Coordinate Normalizer: Converts screen coordinates to a standardized 1000x1000 grid to avoid prompt overhead, then re-scales back to client coordinates.
Action Execution Engine: Dispatches hardware inputs using pyautogui or virtual input device drivers (/dev/uinput on Linux).
Audit & Self-Healing Loop: Records state deltas using Structural Similarity Index (SSIM) and saves structured JSONL execution logs.

3. Implementation: Code & Logic

Step 1: Screen Capture and Coordinate Rescaling

We capture the screen buffer with mss and rescale coordinates between raw monitor resolution and normalized model space (0–1000).

import mss
from PIL import Image
import io

class ScreenCapture:
    def __init__(self, monitor_index: int = 1):
        self.sct = mss.mss()
        self.monitor = self.sct.monitors[monitor_index]
        self.width = self.monitor["width"]
        self.height = self.monitor["height"]

    def capture_frame(self, target_width: int = 1280) -> tuple[bytes, float]:
        sct_img = self.sct.grab(self.monitor)
        raw_image = Image.frombytes("RGB", sct_img.size, sct_img.bgra, "raw", "BGRX")
        
        # Maintain aspect ratio for LLM visual processing
        aspect_ratio = self.height / self.width
        target_height = int(target_width * aspect_ratio)
        resized_image = raw_image.resize((target_width, target_height), Image.Resampling.LANCZOS)
        
        buffer = io.BytesIO()
        resized_image.save(buffer, format="PNG", optimize=True)
        
        # Scale factor relative to native resolution
        scale_factor = target_width / self.width
        return buffer.getvalue(), scale_factor

    def denormalize_coordinates(self, norm_x: int, norm_y: int, grid_size: int = 1000) -> tuple[int, int]:
        """Translates normalized grid coordinates (0-1000) to actual monitor pixels."""
        real_x = self.monitor["left"] + int((norm_x / grid_size) * self.width)
        real_y = self.monitor["top"] + int((norm_y / grid_size) * self.height)
        return real_x, real_y

Step 2: LLM Prompt Structuring & Tool Schema

We enforce structured JSON tool responses so the LLM outputs unambiguous actions and coordinates.

TOOL_DEFINITION = {
    "name": "desktop_action",
    "description": "Execute an input action on the desktop target UI.",
    "input_schema": {
        "type": "object",
        "properties": {
            "action": {
                "type": "string",
                "enum": ["click", "double_click", "right_click", "type", "press_key", "hotkey", "wait", "terminate"]
            },
            "coordinates": {
                "type": "array",
                "items": {"type": "integer"},
                "description": "[x, y] coordinates mapped to a 0-1000 grid. Required for click events."
            },
            "text": {
                "type": "string",
                "description": "Text string to type into input fields."
            },
            "key": {
                "type": "string",
                "description": "Key or key combination to trigger (e.g., 'enter', 'tab', 'ctrl+s')."
            },
            "reasoning": {
                "type": "string",
                "description": "Step-by-step rationale for why this UI element was selected."
            }
        },
        "required": ["action", "reasoning"]
    }
}

Step 3: Hardware Action Execution & State Verification

The dispatcher executes hardware events and captures state confirmation immediately afterward.

import pyautogui
import time
import json
from datetime import datetime

pyautogui.FAILSAFE = True
pyautogui.PAUSE = 0.05

class ActionDispatcher:
    def __init__(self, capture: ScreenCapture, log_path: str = "audit_log.jsonl"):
        self.capture = capture
        self.log_path = log_path

    def dispatch(self, action_payload: dict) -> bool:
        action = action_payload.get("action")
        coords = action_payload.get("coordinates")
        text = action_payload.get("text")
        key = action_payload.get("key")
        
        real_x, real_y = None, None
        if coords and len(coords) == 2:
            real_x, real_y = self.capture.denormalize_coordinates(coords[0], coords[1])

        # Execute action
        if action in ["click", "double_click", "right_click"] and real_x and real_y:
            pyautogui.moveTo(real_x, real_y, duration=0.2)
            if action == "click":
                pyautogui.click()
            elif action == "double_click":
                pyautogui.doubleClick()
            elif action == "right_click":
                pyautogui.rightClick()
                
        elif action == "type" and text:
            pyautogui.write(text, interval=0.02)
            
        elif action == "press_key" and key:
            pyautogui.press(key)
            
        elif action == "hotkey" and key:
            keys = [k.strip() for k in key.split("+")]
            pyautogui.hotkey(*keys)
            
        elif action == "wait":
            time.sleep(2.0)
            
        elif action == "terminate":
            return False

        self._log_audit(action_payload, (real_x, real_y))
        return True

    def _log_audit(self, payload: dict, absolute_coords: tuple):
        log_entry = {
            "timestamp": datetime.utcnow().isoformat(),
            "payload": payload,
            "absolute_coords": absolute_coords
        }
        with open(self.log_path, "a") as f:
            f.write(json.dumps(log_entry) + "\n")

Step 4: The Closed-Loop Execution Loop

This loop orchestrates the screenshot capture, calls the Anthropic API, executes the action, and checks whether the visual state changed.

import base64
from anthropic import Anthropic

def run_autonomous_task(task_instruction: str, max_steps: int = 25):
    client = Anthropic()
    capture = ScreenCapture(monitor_index=1)
    dispatcher = ActionDispatcher(capture=capture)
    
    messages = []
    
    for step in range(max_steps):
        print(f"[*] Executing step {step + 1}/{max_steps}")
        img_bytes, _ = capture.capture_frame(target_width=1280)
        base64_img = base64.b64encode(img_bytes).decode("utf-8")
        
        step_prompt = (
            f"Current task: {task_instruction}\n"
            f"Analyze the provided desktop screenshot. Identify the target element "
            f"and invoke the desktop_action tool. If the task is finished, invoke terminate."
        )
        
        messages.append({
            "role": "user",
            "content": [
                {"type": "text", "text": step_prompt},
                {"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": base64_img}}
            ]
        })
        
        response = client.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=1024,
            tools=[TOOL_DEFINITION],
            tool_choice={"type": "tool", "name": "desktop_action"},
            messages=messages
        )
        
        tool_call = next(c for c in response.content if c.type == "tool_use")
        action_data = tool_call.input
        
        # Append assistant turn to prevent context drift
        messages.append({"role": "assistant", "content": response.content})
        
        continue_running = dispatcher.dispatch(action_data)
        if not continue_running or action_data.get("action") == "terminate":
            print("[+] Task reported complete.")
            break
            
        time.sleep(1.0) # Allow application state to settle

4. Deployment, Rate Limits, and Error Handling

1. Frame Buffer Throttling

Sending entire screen frames per token step can exhaust LLM rate limits (especially TPM limits on images). To handle this:

SSIM Gating: Compute the Structural Similarity Index between consecutive frames. If visual delta is < 1%, do not re-send an image; tell the LLM that the UI hasn't visually updated yet.
Sub-region Cropping: If an active window handle is known, crop the capture strictly to the target bounding box rather than the whole 4K desktop.

2. Guardrails & Failsafes

Always ensure native emergency interrupts remain functional:

Keep pyautogui.FAILSAFE = True enabled. Slamming the mouse into any screen corner immediately raises pyautogui.FailSafeException and aborts execution.
Run tasks within isolated sandboxes, dedicated virtual displays (via Xvfb on Linux), or isolated VMs when automating irreversible accounting or ERP entries.

5. Conclusion & Production Blueprint

Selector-free RPA turns brittle, element-bound automations into reliable computer-use pipelines. By treating UI like human operators do—through visual feedback—you can automate legacy software without maintenance overhead or costly commercial runner licenses.

You can implement this architecture using the snippets above, or deploy our complete, production-hardened template:

Instant Access on Whop: MR Studio Whop
Direct Download on Gumroad: Gumroad Download — Use code EARLYBIRD for 20% off.

The production repository includes:

Full cross-platform window management (X11, macOS Quartz, Win32).
Local SSIM frame-caching to cut LLM token costs by over 60%.
Pre-built error recovery routines with step-level visual debugging.
Complete JSONL schema validators and visual heatmap audit tools.

Aesthetic Trading Automation for Binance

Fri, 09 Oct 2026 05:01:21 +0000

I had an idea waiting up in the pipeline and finally decided to raw the cover over it. I created a trading automation tool which uses multiple trading algorithims under the hood to maximize the gains. I tested 7 different trading algorithimns in 15 different configurations across 12 coins and lab run them in a terminal. However, it turned to be super boring and tedious considering I had to run them time and again for specific intervals.

In order to make it interesting, I turned up my Unity Editor and rolled out a scene to glamour-covering it. I used my claude code to give it a cyberpunk outlook and make the main tower look like a wall street for crypto. Every single tower around the main tower represents a specific algorithim and the respective traded coin.

Note: I have used virtual currency in my project but the models are being trained on the real data. My unity project is linked with my python server through web socket and I am using 3 minute interval candle for training my algorithims.

Tech in qustion: Binance, Python, Unity 3d

Beyond the IFrontend Developer & Automation Buildernterface — Tarek Elzoghby’s Developer Journey

Thu, 08 Oct 2026 12:33:10 +0000

Beyond the Interface — Tarek Elzoghby’s Developer Journey

“I don't stop at the interface — I build the UI and the automation/logic that makes it actually work, as one piece, not two separate jobs.”

For Tarek Elzoghby, becoming a developer started with a practical goal: frontend development looked like the fastest path into freelancing.

But once he started building, something changed.

He became fascinated by the process of watching something grow from nothing into a finished thing he could actually see and use.

That kept him learning.

Today, Tarek describes himself as a self-taught frontend developer who doesn't want to stop at the interface. Alongside HTML, CSS and JavaScript, he's learning n8n, Python and Git, while developing a particular interest in accessibility and automation.

His approach is becoming increasingly clear:

Build the interface. Build the logic behind it. Make the two work together.

Starting With Frontend

Tarek's entry into development was practical.

Frontend looked like the fastest path into freelancing.

But once he started building, he discovered that he genuinely enjoyed the process.

There was something satisfying about watching an idea turn into something visible and functional.

That was enough to keep him going.

Tarek is self-taught, and his learning style is deliberately incremental.

He learns one skill at a time and tries not to move forward until he understands it.

His projects have included a practice website for a fictional ceramics studio, an interactive portfolio and an AI-powered lead classifier.

Alongside frontend development, he's been learning:

n8n
Python
Git

He also keeps a build log for every project.

He writes down what he did, what broke and what he learned.

For Tarek, those notes aren't just documentation.

They're part of the learning process.

Beyond the Interface

The idea that increasingly defines Tarek's work emerged from two projects he built one after another.

The first was his interactive portfolio.

The second was an AI-powered intake classifier built with n8n.

One was primarily frontend.

The other was automation and logic.

Working on them back to back made something click.

They felt like they belonged together.

A website becomes much more useful when something behind the interface can actually handle what visitors do.

A contact form, for example, doesn't have to simply send a message.

Behind it, automation could classify the request, route it to the right person, send an appropriate response and log the information.

Tarek originally planned to connect his portfolio and classifier.

But his plans changed.

Instead, he decided to build his own website from scratch and use it as the place where he could properly bring the two ideas together.

The goal isn't just to talk about combining frontend and automation.

It's to build them as one piece.

Building His Interactive Portfolio

Tarek describes his interactive portfolio honestly:

The whole project was hard.

Most of the time, he knew what he wanted something to look like or how he wanted it to behave.

The difficult part was figuring out how to actually build it.

But one challenge stood out for a different reason.

Writing about himself.

For Tarek, deciding what other people should know about him wasn't easy.

He chose to write the content before touching the HTML.

That decision helped him separate what he wanted to say from how he wanted the website to look.

The result was deliberately straightforward.

He described himself honestly as self-taught and learning one skill at a time.

That approach reflects something that appears repeatedly throughout his development journey:

He prefers understanding and building over pretending he already knows everything.

The Bug That Changed How He Tests

One of the most useful lessons from his portfolio came from a bug he discovered after he thought the project was finished.

He was testing the form's error messages.

At one point, instead of clicking the submit button, he pressed Enter.

The validation didn't run.

He tried again using the mouse.

Everything worked.

That told him the problem wasn't the validation itself.

It was how the form was being submitted.

After investigating, he discovered that his handler had been attached to the button's click event rather than the form's submit event.

The difference mattered.

A form's submit event can occur whether the user clicks the button or presses Enter inside a field.

The fix took only one line.

But the lesson was much bigger.

“Finished and tested” had really meant:

I tested the ways I thought of.

From then on, Tarek started deliberately testing keyboard interactions and other less obvious paths before considering something complete.

It was a small bug.

But it changed the way he thinks about testing.

Learning Automation With n8n and AI

Tarek's AI-powered lead classifier was his first n8n project involving AI.

The idea was straightforward.

A client submits a project through a form.

An LLM classifies the request into one of five categories.

The workflow then sends the appropriate client email, sends an internal notification and records the information in Google Sheets.

But building it taught Tarek that AI automation isn't primarily about getting the model to produce the correct answer.

A large part of the engineering work is deciding:

What happens when the AI gets it wrong?

He approached that problem in several ways.

Structured Output

Instead of relying on free-form text, he used structured output with a JSON schema.

That meant the model had to return data in a defined shape, allowing the workflow to branch on predictable fields rather than trying to interpret loose text.

Ambiguous vs Invalid

Tarek also separated two situations that could easily be treated as the same problem.

An input that genuinely fits two categories is ambiguous.

An input that isn't a project at all is invalid.

Those situations require different handling.

Retry and Human Review

He also designed for failure.

If classification fails, the workflow retries three times with five-second intervals.

If it still fails, the system falls back to a human-review path labelled as a system error.

The client's original data is preserved.

Tarek even tested the failure behaviour himself by cutting his network connection during a run and watching the workflow recover instead of simply crashing.

Testing the Whole System, Not Just the Nodes

Another lesson from the n8n project was that successful workflow execution doesn't necessarily mean the system is working correctly.

Tarek didn't stop at checking whether the workflow nodes completed.

He checked the actual inboxes.

That revealed a bug where the internal notification and client email destinations had been swapped.

The workflow technically ran.

But it was still wrong.

He also tested the AI prompt with deliberately tricky descriptions.

That exposed situations where the classifier was guessing between categories rather than identifying them as ambiguous.

He then rewrote the prompt to handle those cases more clearly.

For Tarek, this reinforced an important principle:

Testing isn't just checking whether the workflow runs.

It's checking whether the system does what it is supposed to do in the real world.

Accessibility Is Becoming a Specialisation

Accessibility isn't something Tarek treats as an optional extra.

Part of that comes from his personality.

He's detail-oriented and likes making things work properly.

But his motivation goes beyond technical correctness.

He believes people should be able to have the same experience on a website regardless of what they can or cannot do.

Accessibility, in his view, should be part of building a website by default.

He is particularly interested in the fact that technology can make the web much more accessible to people who use screen readers.

Being able to contribute to that experience is a major reason accessibility is becoming a specialization for him.

When 100 Isn't Really 100

One of Tarek's strongest accessibility lessons came from a project that achieved a 100 Lighthouse accessibility score.

It would have been easy to stop there.

But Tarek tested the site manually with NVDA.

That's when he found something the automated audit had not caught.

An <address> element containing a heading wasn't valid HTML in the way it was being used, and NVDA announced it as a normal region.

The automated score hadn't identified the problem.

The screen reader did.

That experience reinforced something Tarek now believes strongly:

A perfect automated accessibility score does not mean a website is accessible.

Automated tools can only check what they are designed to check.

Someone still needs to experience the page using assistive technology.

Tarek has tested with NVDA himself and recognizes that there is still much more for him to learn.

That willingness to keep learning is part of what makes accessibility an interesting direction for his development journey.

Learning Through Practice

Tarek's projects are deliberately practical.

Even when something is technically a practice project, he tends to build it as if he might actually use it.

That approach has one downside.

He can keep adding features forever.

To prevent that, he changed how he structures projects.

He now works in stages.

He plans a stage.

He completes it.

Then he stops.

Anything outside that stage goes into a notes file rather than immediately becoming another feature.

Once all planned stages are finished, he reviews the notes and treats the ideas as potential future projects.

Then he decides which ones are actually worth pursuing.

This gives him a way to stay curious without allowing every new idea to derail the current project.

Search, Test, Understand

When Tarek doesn't know how to do something, his process is simple.

He searches for answers.

He tests them.

Then he checks what is actually happening instead of simply assuming the solution worked.

His n8n classifier provided a good example.

At one point, something wasn't behaving as expected.

Rather than immediately blaming the AI model, he looked at the model's raw output.

That showed him that the model was actually fine.

The problem was somewhere else in the workflow.

This is becoming an important part of his learning philosophy:

Don't guess when you can inspect.

Building His Own Website

Tarek's next major project is his own website.

It represents a step up from what he has built so far.

His previous projects have primarily been one-page landing pages.

This time, he's building a full multi-page website with different sections and responsibilities.

It's taking a significant amount of his time.

But it's also teaching him a lot.

The site will be hosted on GitHub, which means Git and GitHub Actions are becoming increasingly important parts of his workflow.

He sees those skills as another layer supporting the frontend and automation work he is already doing.

Why Python and n8n Matter

Tarek sees the technologies he's learning as connected rather than isolated.

n8n represents the automation side of his work.

Frontend represents the interface.

Python provides another useful programming foundation.

He believes Python is valuable for developers because it appears in so many tools and scripting workflows.

Knowing Python also means being able to create custom scripts that fit the way he works rather than always relying on someone else's tooling.

Git and GitHub then provide the workflow and infrastructure around the projects.

Instead of collecting technologies simply for the sake of learning them, Tarek is gradually building a toolkit around the kind of developer he wants to become.

The Challenge of Learning Alone

Being self-taught and mostly working independently comes with another challenge that isn't technical.

Community.

Tarek has found that meeting people and becoming part of the developer community requires real effort when you're learning and building mostly on your own.

In fact, he says that putting effort into connecting with people has been surprisingly more difficult than any project he's worked on.

That's one reason CoderLegion has become relevant to his journey.

He isn't only building technical skills.

He's also trying to find other people who are learning, building and figuring things out along the way.

Advice From a Beginner

Tarek is careful about giving advice.

He doesn't claim to have everything figured out.

He's still a beginner himself.

So instead of presenting a formula for success, he shares what has been working for him.

Stay organized

A good folder structure can save a surprising amount of time.

Set it up before the project becomes messy.

Write things down

His project notes help him remember how an idea started, how a problem was solved and what he learned from the process.

Those notes become a record of his mistakes and lessons.

Break problems down

Don't treat a difficult problem as one enormous problem.

Define what you want to achieve.

Break it into smaller steps.

Then work on one step at a time.

Often, the solution turns out to be easier to find than the original problem made it feel.

Practice while learning

Don't wait until you've mastered something before using it.

Practice what you're learning.

Then learn more while you're practicing.

For Tarek, focusing on the next small thing is what prevents the learning process from becoming overwhelming.

Frontend and Automation as One Direction

Tarek's current focus is clear.

He wants to become good at both frontend development and automation and eventually bring them together.

In the near term, he's aiming for freelance frontend and automation work.

Longer term, he would like to build something of his own—a space where he can create projects across different areas of technology and experiment with how those areas connect.

But he's not trying to rush there.

For now, the priority is simple:

Learn. Build. Improve.

One step at a time.

Learning to Walk Before Running

Tarek's approach to the future is deliberately grounded.

He's trying to learn to walk before he runs.

That means focusing more on today than on an imagined distant destination.

At the same time, he believes knowing what you want to become helps shape who you are today.

Right now, that means developing his skills in frontend development and automation.

Later, it may mean building something of his own.

But the immediate goal isn't to skip ahead.

It's to build the foundation properly.

A Message to Other Self-Taught Developers

Tarek has one simple message for people in a similar position.

If you're self-taught and mostly working alone, finding people to connect with takes real effort.

So if you're on the same path, don't assume you're the only one.

Reach out.

Build connections.

Share what you're learning.

And keep building.

You don't need to have everything figured out before you become part of a community.

Sometimes learning alongside other people is part of figuring it out.

Beyond the Interface

Tarek's journey is still at an early stage.

But there is already a clear direction.

He started with frontend because it seemed like the fastest path into freelancing.

He stayed because he discovered how much he enjoyed building.

Then he began looking beyond the interface.

Automation showed him what could happen behind a form.

AI introduced new questions about reliability and failure handling.

Accessibility showed him that technical correctness and real user experience aren't always the same thing.

And his projects continue to teach him that the best way to learn is often to build something, break something, investigate it and try again.

His goal isn't simply to become someone who can create attractive interfaces.

He wants to understand what happens behind them.

The interface.

The automation.

The logic.

The accessibility.

The systems connecting everything together.

And eventually, he wants to build all of those pieces as one.

About Tarek Elzoghby

Tarek Elzoghby is a self-taught frontend developer focused on building interfaces together with the automation and logic that make them work.

His technical interests include JavaScript, HTML, CSS, n8n, Python, Git and accessibility.

His projects include interactive frontend experiences, AI-powered workflow automation and accessibility-focused web development.

View Tarek's profile on CoderLegion

Visit Tarek's portfolio hub

CoderLegion Developer Stories

Real developers. Real journeys. Real experiences.

Developer Stories at CoderLegion gives developers an opportunity to share how they think, what they build, the problems they encounter and what they learn along the way.

Interview & Story by Mehadi Hasan

From Shared Drives to Structured Systems: Solving the Accounting Document Management Problem in Indi

Thu, 08 Oct 2026 08:05:30 +0000

Ask an accounting firm in India where a client's Form 16 is, and you will usually get a pause. Then a few guesses. It might be in the client's WhatsApp group, in an email from March, on the office server under "ITR 2024 final", or on a junior's laptop.

Nobody is careless here. The firm simply grew faster than its filing habits. A shared drive that worked for ten clients quietly stopped working at a hundred, and nobody picked the day to fix it.

This article looks at why shared drives fail accounting practices, what a structured system does differently, and what to check before you choose a document management solution in India.

Why the shared drive lasted so long

A shared drive is the path of least resistance. It costs almost nothing, everyone understands folders, and it needs no training. For a small practice handling a few dozen clients, it is a reasonable starting point.

The trouble is that a folder tree only works while everyone follows the same unwritten rules. One person files by client name, another by assessment year, a third by document type. Someone adds "final" to a filename, someone else adds "final_revised". The structure lives in people's heads, and heads change jobs.

Where it breaks

The failure is gradual. Four symptoms usually show up first:

Duplicate versions. Two staff edit the same computation sheet. Whoever saves last wins, and nobody knows what was lost.
Slow retrieval. Finding last year's balance sheet means opening five folders and guessing which PDF is the signed one.
No history. When a partner asks who changed a figure and when, the honest answer is "we can't tell".
Loose access. Everyone sees every client's PAN, bank statements and financials, because setting permissions folder by folder is tedious.

Add the way documents actually reach an Indian practice. Clients send phone photos on WhatsApp, vendors email attachments, and reception scans paper. Each channel creates files outside the drive, which someone must download, rename and upload by hand. Under deadline pressure, that step gets skipped.

What "structured" actually means

It helps to think of a document management system the way a developer thinks about a data model. A shared drive stores blobs with names. A structured system stores records with relationships and rules.

Entities. Every client and engagement is its own workspace, so a document always belongs to something specific. Nothing floats.

Metadata. Each document carries fields such as type, party, dates, amounts and identifiers. You can filter by assessment year or document type without relying on anyone's naming style.

Permissions. Access is defined per person or group, can be inherited from a folder, and can be overridden on a single file.

Versions. A revision is added, never overwritten. Each one carries its author and timestamp, and any earlier version can be restored.

Locks. Check-in/check-out gives a file one editor at a time. The system records who holds it and since when.

Audit log. Every open, download, edit, share and deletion is written to a record that cannot be edited afterwards.

None of this is exotic. It is the same discipline software teams already apply to code, applied to client files.

Why cloud, and why it matters in India

Cloud document management software in India solves a practical problem first: your team is no longer tied to one office server. Partners can review a file from home, articles can work from a client's premises, and nobody keeps a "just in case" copy on a pen drive.

The question that matters more is where the data lives. Firms handle PAN details, GST records, bank statements and audit files. With the Digital Personal Data Protection Act in force and many firms keeping internal data-localisation policies, "in the cloud" is not a complete answer. Better questions are:

Can we choose the region the data sits in?
Is there a dedicated single-tenant option, or an on-premise install behind our own firewall?
Is data encrypted in transit and at rest, and who holds the keys?
Can the vendor's own staff browse our documents?

A good provider answers these plainly. Managed cloud suits most practices. Larger firms or those with strict client contracts may want a dedicated instance or an on-premise deployment, ideally from the same codebase so features don't differ.

The AI layer, and what it should and shouldn't do

Older systems asked staff to tag every document by hand, which works for a month and then quietly stops. AI document management software in India changes that by reading what a document says instead of trusting its filename.

For an accounting practice, the useful parts are specific:

Automatic categorisation. Income tax returns, Form 16s, GST returns, balance sheets and audit reports are recognised on arrival.
Field extraction. PAN, assessment year, amounts and TDS details are pulled into searchable fields without anyone typing them.
Deadlines from documents. Due dates and periods are read from the files themselves instead of a calendar someone has to maintain.
Plain-language search. You ask "what was the total TDS deducted for this client in Q2?" and get an answer.

The last item is where discipline matters. An accountant signs their name to the work, so an unsourced answer is a liability. A trustworthy system ties each answer to the exact passage it came from, so you can open the source document with the line highlighted and verify in seconds. When no document supports an answer, it should say so instead of guessing.

A sensible system also asks before it acts. It proposes a record type, a filename and a destination, and a person confirms. Anything it is unsure about gets flagged for review.

Capturing documents where they already arrive

Better folders do not fix the intake problem. Asking clients to install an app or remember a portal login rarely works, and they go back to WhatsApp within a week.

The more workable approach is to capture documents at the source:

A separate firm WhatsApp Business number, not a partner's personal phone.
A mailbox watched for attachments only, scoped to a shared address, specific folders or particular senders.
The office scanner, including phone photos of paper.
Direct upload, including whole folders.

Each file arrives with its origin, sender and timestamp recorded, which later answers "when did the client actually send this?" Phone photos are often skewed, blurry or badly lit, so OCR needs to handle that as the normal case, and unreadable fields should be flagged instead of guessed.

Intellodocs, an AI-native document vault from Imbibe Technologies, is built around this capture-first idea. It pulls documents in from WhatsApp, email and direct upload, classifies them, extracts key fields, and files them into client and matter workspaces with versioning, check-in/check-out, per-file permissions and an immutable access log underneath. It is in early access, and its site is open about what Phase 1 does not include yet: native Gmail and Outlook connectors, e-signature, drafting and Tally sync. That is worth knowing if your workflow depends on any of them.

How to evaluate options without getting lost in feature lists

When people search for the best document management software in India, they usually end up with a long comparison table. For an accounting firm, a few checks matter more than the length of the list.

Does it stop overwrites? Locking and version history are basic requirements.
Does it capture what clients already send? If WhatsApp and email documents still need manual uploading, staff will drift back to old habits.
Where does the data sit, and who controls the keys? Ask for specifics, not assurances.
How granular is access? Juniors should see their own briefs, partners everything, and clients only their files.
Can you leave? You should be able to export original files, folder structure, metadata and the full audit log in open formats, with no exit fee.
How is migration handled? Ask who moves your existing folders and whether you can review the mapping before it goes live.
Is the vendor honest about gaps? A clear list of what is not built yet is a better sign than a promise to do everything.

Moving over without disrupting the team

Most failed rollouts try to change everything at once. A calmer path looks like this:

Start with one team or a small set of clients, not the whole firm.
Migrate the current financial year first and leave older years for a second pass.
Set permission rules before anyone starts filing, because fixing access later is painful.
Keep the old shared drive read-only for a few months, so nobody feels stranded.
Count how often someone asks "which is the latest file?" before and after. That number tells you whether the change worked.

A system that captures documents on the channels people already use also needs far less training, because staff are not asked to change how clients behave.

The shift that matters

The move from shared drives to structured systems is not about adopting new software for its own sake. It is about moving the rules out of people's heads and into the system. When the platform handles locking, versioning, access and logging, discipline no longer depends on who is having a good week.

Indian accounting practices are carrying more clients, more compliance deadlines and more personal data every year. A structured, cloud-based document management solution is becoming basic infrastructure for them, much as version control became basic infrastructure for software teams. The sooner "final_v3" disappears from your folders, the sooner your team can get back to the work you actually bill for.

Building Practical Python Tools That Solve Real World Problems

Thu, 08 Oct 2026 05:09:45 +0000

Python is one of those technologies that makes it possible to turn an everyday problem into a working solution with relatively little code.

For me, Python development is not only about writing programs or learning new frameworks. It is about finding problems that people deal with every day and building tools that make those problems easier to solve.

Many businesses still spend hours doing repetitive tasks manually. Copying information between spreadsheets, preparing reports, processing files, checking records, sending data to different systems, or updating databases may seem like small tasks individually. But when they are repeated every day, they can consume a significant amount of time.

This is where I enjoy using Python.

Why I Focus on Practical Python Development

I enjoy building software that has a clear purpose.

Instead of creating applications simply because a technology is interesting, I prefer projects where the result can actually help someone work faster, reduce errors, or manage information more efficiently.

Python provides a great environment for this because it can be used for many different types of problems.

I work with technologies such as Python, Tkinter, CustomTkinter, SQLite, APIs, Pandas, OpenPyXL, and automation tools to build practical applications and scripts.

Sometimes the solution is a small automation script.

Sometimes it is a desktop application.

Sometimes it involves processing hundreds or thousands of rows from an Excel file.

And sometimes the solution requires connecting different systems through an API.

The technology can change, but the goal remains the same:

Build something useful that solves a real problem.

Turning Repetitive Work Into Automation

One of the areas I enjoy most is automation.

Repetitive work is everywhere.

A person may need to open an Excel file, check certain values, filter information, update another spreadsheet, create a report, and repeat the same process every day.

If a task follows predictable rules, there is a good chance that Python can help automate at least part of it.

For example, a Python automation tool can:

Read data from Excel files
Process and clean information
Find specific records
Generate reports
Update databases
Communicate with APIs
Rename or organize files
Perform calculations
Create new Excel reports
Reduce repetitive manual operations

The interesting part is not simply writing the script.

The real challenge is understanding how the existing process works and then deciding how technology can improve it.

A good automation solution should make work simpler without creating unnecessary complexity.

Working With Excel Data

Excel is still heavily used in many businesses.

Even when a company has other systems, Excel often remains part of the daily workflow.

This is why working with Excel programmatically is a useful skill.

With Python and libraries such as Pandas and OpenPyXL, it is possible to process large amounts of spreadsheet data much more efficiently.

For example, imagine someone receives a spreadsheet containing thousands of records.

Manually checking every row can take hours.

A Python application could read the file, validate the information, identify missing values, filter records based on specific conditions, perform calculations, and generate a cleaned or summarized version.

The goal is not necessarily to replace Excel.

The goal is to remove unnecessary manual work around Excel.

That distinction is important.

Technology should fit into the business process rather than force people to completely change how they work.

Building Simple Desktop Applications

Not every business problem needs a web application.

Sometimes a simple desktop application is the better solution.

This is where Tkinter and CustomTkinter become useful.

With these tools, I can build graphical interfaces that allow users to interact with Python applications without needing to run commands from a terminal.

A user might need to:

Select an Excel file
Enter some information
Click a button
Process the data
View results
Export a report

Instead of requiring technical knowledge, a graphical interface can make the tool much easier to use.

I particularly enjoy this part of development because it combines programming with usability.

A tool is more valuable when the person using it does not need to understand how the code works.

SQLite for Lightweight Data Management

When an application needs to store structured information, SQLite can be a practical choice.

It is lightweight, simple to configure, and does not require a separate database server for many desktop and small-business applications.

For example, a Python application could use SQLite to store:

Customer information
Product records
Transaction history
Application settings
Processed files
User activity
Reports or generated records

Combining Python with SQLite makes it possible to create useful applications without introducing unnecessary infrastructure.

For small and medium-sized tools, this can be a very effective approach.

Connecting Applications With APIs

Modern applications rarely work completely on their own.

Businesses often use multiple systems, and those systems need to exchange information.

APIs make this possible.

With Python, I can work with APIs to retrieve information from external services, send data to another system, or connect different parts of a workflow.

For example, an automation tool might retrieve information from an API, process it using Python, store important data in SQLite, and finally generate an Excel report.

This creates a workflow where multiple technologies work together.

The interesting part is seeing how these pieces can be connected to create something useful.

Learning Through Projects

One thing I have learned while improving my Python skills is that projects teach differently from tutorials.

A tutorial can explain how a library works.

But a real project forces you to think about things that tutorials sometimes do not cover.

What happens when the input file is empty?

What if a column is missing?

What if the API does not respond?

What if the user enters invalid information?

What happens when thousands of records need to be processed?

These situations require problem-solving.

Writing code is only one part of development. Understanding what can go wrong is another important part.

That is why I prefer learning by building.

Every project gives me an opportunity to experiment, make mistakes, debug problems, improve the code, and understand Python more deeply.

From Small Scripts to Useful Applications

Many useful applications start as very small ideas.

A simple script might begin with:

"I don't want to do this manually anymore."

That idea can eventually become a complete application.

For example:

Manual process → Python script → improved workflow → graphical interface → database → complete business tool

The technology grows as the problem requires it.

This approach helps avoid overengineering.

Instead of starting with a complicated architecture, I prefer starting with the actual problem and building what is necessary.

The Importance of Understanding the Business Problem

Being a developer is not only about knowing programming languages.

A developer also needs to understand why something needs to be built.

Imagine someone asks for an application that automatically processes an Excel file.

Before writing code, there are several questions worth asking.

What information is inside the file?

How often is the process performed?

What mistakes happen during the manual process?

What should happen when data is missing?

What should the final output look like?

Who will use the application?

How much time should the automation save?

These questions help turn a vague request into a practical solution.

The best technical solution is not always the most complicated one. It is the one that solves the actual problem effectively.

What I Am Continuing to Learn

Python development is a continuous learning process.

There is always another library, framework, technique, or concept to explore.

I am continuously improving my understanding of Python and experimenting with different ways to build better tools.

My interests include automation, data processing, desktop applications, APIs, databases, and practical business software.

I also enjoy exploring how different technologies can work together.

For me, learning becomes more meaningful when I can apply it to a real project.

Instead of only asking, "How does this technology work?"

I like asking:

"What problem can I solve with it?"

That question changes the way I approach development.

Building Technology Around People

Automation should not make work more complicated.

It should make work easier.

A successful tool does not necessarily need hundreds of features. Sometimes a small application that saves someone 30 minutes every day can be more valuable than a large system filled with features that nobody uses.

That is the type of development I enjoy.

I want to build tools that are practical, understandable, and useful.

Whether it is a Python script that automates a repetitive task, a CustomTkinter application that simplifies a workflow, a SQLite database that organizes information, or a Pandas/OpenPyXL solution that processes large spreadsheets, the objective is the same:

Use technology to solve problems.

Looking Ahead

My journey with Python is still continuing.

There are many areas I want to explore further, improve my development practices, and apply what I learn to larger and more useful projects.

I want to keep building software that connects programming with real business needs.

The more I work on practical projects, the more I understand that development is not simply about writing code.

It is about observing problems, understanding requirements, experimenting with solutions, learning from mistakes, and continuously improving the final result.

That is what keeps Python development interesting for me.

There will always be another repetitive task to automate, another workflow to improve, another problem to solve, and another idea to turn into a working application.

And that is exactly what I enjoy about being a Python-focused developer.

Keep learning. Keep building. Keep solving real problems with code.

I Built an AI Voice-to-Database Assistant to Save My Friend 2 Hours a Day 🎙️

Wed, 07 Oct 2026 18:47:43 +0000

The Problem: My Friend's Nightly Struggle

My friend Carlos is a field supervisor in the construction industry. He spends his entire day walking around sites, inspecting materials, and dealing with contractors. But his real nightmare began at 6:00 PM: he had to sit down for two hours to manually transcribe all his messy WhatsApp voice notes into his company's structured Google Sheets and PowerBI dashboards.

He was exhausted, and his family missed him in the evenings. I knew I had to build something for him.

What I Built

I built a WhatsApp-based AI assistant that completely automates his data entry. Now, Carlos just sends a WhatsApp voice note like: "Today we received 50 bags of cement from supplier X, but 3 were damaged. Total cost \$250."

The system automatically:

Receives the audio via Webhook.
Downloads the .ogg file using the WhatsApp Business API.
Transcribes the audio using Whisper (Open-Source AI).
Extracts the exact entities (Material, Quantity, Status, Cost) using an LLM.
Pushes the clean, structured JSON directly into his Google Sheets.

Demo & Architecture

Here is a look under the hood using Make (formerly Integromat) to orchestrate the workflow:

(If you want to see the exact step-by-step technical guide on how I solved the tricky WhatsApp Media ID download, check out my deep-dive technical post on DEV.to)

Why Open Innovation Matters for This Project

Open-source AI is the absolute core of this solution, specifically OpenAI's Whisper model.

For Carlos, open innovation matters for two critical reasons:

Language & Slang: Carlos speaks Spanish with heavy local construction slang. Proprietary, rigid voice-to-text models fail miserably at this. Whisper's open-source architecture allows for incredibly robust multilingual transcription that actually understands him.
Future Data Privacy: Because Whisper is open-source, if Carlos's company ever demands strict data privacy (keeping audio files off third-party servers), we have the freedom to take this exact workflow and run Whisper locally on a private server or even a laptop on the construction site with no internet. Open innovation gives us the flexibility to scale without vendor lock-in.

I handed the bot over to Carlos yesterday. His response? "You just gave me my evenings back." That's the power of building for a friend. 🚀

Building an Autonomous CI/CD Log Triage & Self-Healing PR Engine with Python and DuckDB

Wed, 07 Oct 2026 17:14:08 +0000

Building an Autonomous CI/CD Log Triage & Self-Healing PR Engine with Python and DuckDB

Every growing engineering team hits the same wall: CI pipelines fail, developers ignore cryptic 200MB console outputs, and senior engineers spend 15+ hours every week parsing raw text to fix the same 4 recurring issues—broken lockfiles, misconfigured test fixtures, missing environment variables, or dependency drift.

Observability vendors sell multi-thousand-dollar enterprise suites to ingest these logs, yet they stop at alerting. You still have to open the console, copy the stack trace, diagnose the problem, create a branch, write the fix, and submit a PR.

In this guide, we'll build a zero-infrastructure, self-healing pipeline that runs natively inside your CI environment (GitHub Actions, GitLab CI, or n8n runner). It parses multi-gigabyte build artifacts using DuckDB, clusters stack traces deterministically without bloated vector stores, prompts an LLM with compact context, and automatically submits self-healing Pull Requests via the GitHub REST API.

1. The Bottleneck: Why Traditional Log Triage Fails

Most CI log monitoring tools fail for three architectural reasons:

Data Transfer Tax & Latency: Pushing gigabytes of raw container logs over the wire to external aggregators creates latency and ballooning bandwidth bills.
Vector DB Overhead: Vector embeddings for error logs are overkill. Logs are semi-structured text where 95% of lines are identical runtime noise. Embedding entire raw logs produces polluted semantic spaces that fail to isolate exact trace boundaries.
Lack of Actionability: Alerting on Slack is not a resolution. If a failure stems from a deprecated dependency version or a missing mock key, the remediation step is deterministic.

By executing triage locally on the CI runner, we eliminate network egress, process logs in memory via columnar storage, and resolve routine failures without human intervention.

2. System Architecture

The engine follows a strict four-stage pipeline running directly on your CI execution container:

[ Raw CI Log Files (*.log, *.json) ]
              │
              ▼
┌───────────────────────────────┐
│ DuckDB High-Throughput Ingest │ ──► Columnar filtering of timestamps,
│ & Regex Pattern Clustering    │     log levels, and stack frames
└──────────────┬────────────────┘
              │
              ▼
┌───────────────────────────────┐
│ Deterministic Triage Engine   │ ──► Isolates exact stack trace and
│ (Root-Cause Classifier)       │     queries target source file
└──────────────┬────────────────┘
              │
              ▼
┌───────────────────────────────┐
│ Structured LLM Patch Synthesizer │ ──► Generates unified diff
└──────────────┬────────────────┘
              │
              ▼
[ GitHub REST API: Creates Git Branch + Opens Self-Healing PR ]

DuckDB: Reads gigabyte-scale logs directly from disk or gzipped archives using zero-copy SQL queries.
Pattern Clustering: Groups repeated log lines using tokenized signature matching.
Autonomous Git Engine: Validates the proposed diff locally, branches out, commits the patch, and triggers a PR.

3. The Code & Implementation

Step 1: Sub-Second Log Parsing with DuckDB

Instead of loading logs line-by-line in pure Python, we leverage DuckDB's native regex parsing engine to query the raw log file as a relational table.

import duckdb
import os

def extract_critical_failures(log_path: str) -> list[dict]:
    """
    Parses uncompressed or gzipped logs and extracts error frames
    without loading the entire file into Python memory.
    """
    con = duckdb.connect(database=":memory:")
    
    query = """
    WITH raw_lines AS (
        SELECT 
            row_number() OVER () AS line_num,
            column0 AS content
        FROM read_csv(?, header=False, sep='\n', auto_detect=False)
    ),
    filtered_errors AS (
        SELECT 
            line_num, 
            content,
            regexp_extract(content, '(?i)(error|fatal|exception|failed):?\s*(.*)', 2) AS error_msg
        FROM raw_lines
        WHERE regexp_matches(content, '(?i)(ERROR|FATAL|Exception|FAILED)')
    )
    SELECT 
        line_num, 
        content, 
        error_msg
    FROM filtered_errors
    LIMIT 25;
    """
    
    results = con.execute(query, [log_path]).fetchall()
    con.close()
    
    return [{"line": row[0], "raw": row[1], "error": row[2]} for row in results]

Step 2: Extracting Context Around the Root Failure

Once DuckDB pinpoints the fatal line number, we extract the local stack trace window and the affected source code file to pass to our LLM generator.

import re
from pathlib import Path

def isolate_trace_context(log_path: str, error_line: int, window: int = 15) -> str:
    """Extracts preceding and succeeding context around an error line."""
    start = max(1, error_line - window)
    end = error_line + window
    
    con = duckdb.connect(database=":memory:")
    query = """
    SELECT list(column0)
    FROM (
        SELECT row_number() OVER () AS rn, column0
        FROM read_csv(?, header=False, sep='\n', auto_detect=False)
    )
    WHERE rn BETWEEN ? AND ?;
    """
    lines = con.execute(query, [log_path, start, end]).fetchone()[0]
    con.close()
    return "\n".join(lines) if lines else ""

def locate_offending_file(trace_text: str) -> tuple[str, str]:
    """Locates local source code file and extracts code content."""
    file_match = re.search(r'File "([a-zA-Z0-9_\-\./]+\.py)", line (\d+)', trace_text)
    if not file_match:
        return "", ""
    
    file_path, line_no = file_match.group(1), int(file_match.group(2))
    if Path(file_path).exists():
        return file_path, Path(file_path).read_text()
    return "", ""

Step 3: LLM Patch Synthesizer & GitHub PR Automation

We feed the trace and target source code into a structured LLM prompt that enforces raw unified diff output, then push the patch directly through the GitHub API.

import json
import urllib.request
import base64

def generate_patch_with_llm(trace: str, source_code: str, file_path: str, api_key: str) -> str:
    """Generates a strict unified diff to fix the identified CI breakage."""
    system_prompt = (
        "You are an automated CI remediation agent. Analyze the provided test failure "
        "and source code. Output ONLY a valid unified diff (git patch) that fixes the failure. "
        "Do not output markdown code blocks, explanations, or commentary."
    )
    user_prompt = f"TARGET FILE: {file_path}\n\nSTACK TRACE:\n{trace}\n\nSOURCE CODE:\n{source_code}"
    
    payload = json.dumps({
        "model": "gpt-4o-mini",
        "messages": [
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt}
        ],
        "temperature": 0.1
    }).encode("utf-8")
    
    req = urllib.request.Request(
        "https://api.openai.com/v1/chat/completions",
        data=payload,
        headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"}
    )
    
    with urllib.request.urlopen(req) as resp:
        data = json.loads(resp.read().decode("utf-8"))
        return data["choices"][0]["message"]["content"].strip()

def create_self_healing_pr(repo: str, branch: str, file_path: str, updated_content: str, token: str):
    """Applies remediation by opening a Git branch and PR via GitHub REST API."""
    headers = {
        "Authorization": f"Bearer {token}",
        "Accept": "application/vnd.github.v3+json"
    }
    base_url = f"https://api.github.com/repos/{repo}"
    
    # 1. Fetch default branch SHA
    req = urllib.request.Request(f"{base_url}/git/ref/heads/main", headers=headers)
    with urllib.request.urlopen(req) as resp:
        sha = json.loads(resp.read().decode())["object"]["sha"]
        
    # 2. Create target branch
    branch_payload = json.dumps({"ref": f"refs/heads/{branch}", "sha": sha}).encode()
    req = urllib.request.Request(f"{base_url}/git/refs", data=branch_payload, headers=headers)
    urllib.request.urlopen(req)
    
    # 3. Fetch file SHA
    req = urllib.request.Request(f"{base_url}/contents/{file_path}?ref={branch}", headers=headers)
    with urllib.request.urlopen(req) as resp:
        file_sha = json.loads(resp.read().decode())["sha"]
        
    # 4. Commit updated file
    encoded_content = base64.b64encode(updated_content.encode()).decode()
    commit_payload = json.dumps({
        "message": "fix(ci): autonomous self-healing patch for test failure",
        "content": encoded_content,
        "sha": file_sha,
        "branch": branch
    }).encode()
    req = urllib.request.Request(f"{base_url}/contents/{file_path}", data=commit_payload, headers=headers, method="PUT")
    urllib.request.urlopen(req)
    
    # 5. Open Pull Request
    pr_payload = json.dumps({
        "title": "🤖 [Self-Healing] Fix CI Failure Regression",
        "head": branch,
        "base": "main",
        "body": "This Pull Request was automatically generated by the Autonomous CI Log Triage Engine after detecting deterministic failures in the pipeline."
    }).encode()
    req = urllib.request.Request(f"{base_url}/pulls", data=pr_payload, headers=headers)
    urllib.request.urlopen(req)

4. Deployment, Timeouts, and Rate Limits

To run this in production without adding latency to green runs:

Conditional Triggers: Only execute the triage step on if: failure() in GitHub Actions or when: on_failure in GitLab CI.
Run-Time Budgets: Restrict the DuckDB scan window to the last 5,000 lines. DuckDB handles this in under 200ms.
LLM Cost Guardrails: Strip ANSI escape codes (\x1b\[[0-9;]*m) before sending payloads to LLMs to prevent token inflation. Truncate context to include only the stack trace boundary and the active function block.
Prevent PR Flooding: Cache the hash of the error signature (MD5(trace_text)) in your build cache. If an identical PR is already pending, skip recreation.

5. Conclusion & Ready-to-Use Workflow

You can implement this architecture using the code snippets above or integrate it into an automated n8n webhook listener. By replacing third-party SaaS log aggregators with embedded DuckDB queries, you gain deterministic triage while keeping logs completely inside your security perimeter.

If you prefer a plug-and-play solution, you can get the complete turnkey package containing production GitHub Action workflows, Docker container configurations, synthetic log test fixtures, and pre-built n8n triage workflows:

Instant Access on Whop
Direct Download on Gumroad (Use promo code EARLYBIRD for 20% off)

The Lazy Developer's Guide to Automated Versioning

Tue, 06 Oct 2026 12:10:33 +0000

If you have a workflow like mine—constantly context-switching between iOS, macOS, Flask/Python, and more—you know the chaos. You're making countless changes, pushing a bombardment of commits, especially in early-stage, pre-release projects. Amidst all this, is there something you constantly forget or overlook?

Versioning!

Recently, I realized that no matter how hard I tried to pay attention, I wasn't giving versioning the care it deserved. I decided to put an end to this once and for all.

Automated Versioning!

You know the drill. You’re in the zone. You’re fixing bugs, refactoring spaghetti code, and pushing commits like there’s no tomorrow.

git commit -m "fix typo"
git commit -m "refactor logic"
git commit -m "oops, broke it, fixed again"

And then, three weeks later, you look at your setup.py or package.json and it still stares back at you: version: 0.0.1.

Imagine this scenario: unless you specify otherwise, the project's single, main version automatically updates with every commit. At the same time, if you wish, you can trigger specific version bumps (major, minor) just by tagging the importance of your change in the commit message, without ever touching a version number manually.

Sounds logical, doesn't it?

I implemented this for my own workflow, and now versioning requires zero effort. I can bump the version just by indicating the change's importance in the commit message. And if I don't say anything? The patch version increments automatically.

If you're suffering from the same headache, here is how you can add this logic to your projects.

The Problem: "Where did I put that version number again?"

The "I'll do it later" Syndrome: When you’re rapid prototyping, stopping to manually increment a number feels like a speed bump on a highway. So you likely keep going without incrementing the version for each change.
The Scavenger Hunt: In some projects, version numbers are scattered across package.json, setup.py, and more. Even worse, they often show different numbers.

I’m lazy enough to want to get rid of these headaches. As they say, Laziness is the mother of invention.

The Solution

Let Git do the heavy lifting. My goal? Whenever I type git commit, I want the version to bump itself.

Step 1: The Single Source of Truth

First, I stopped the madness of having multiple version sources by creating a single, dedicated file: src/version.py.

__version__ = "1.0.0"

Step 2: The Worker Bee (Script + Hook)

We need two things:

A Python script to do the math (increment numbers).
A Git Hook to trigger it automatically when you commit.

2.1 The Python Script

Create scripts/bump_version.py. This script reads the BUMP environment variable and updates src/version.py.

#!/usr/bin/env python3
import re
import sys
import os
from pathlib import Path

# Define version file path
PROJECT_ROOT = Path(__file__).parent.parent
VERSION_FILE = PROJECT_ROOT / "src" / "version.py"

def bump_version():
    if not VERSION_FILE.exists():
        print(f"Error: Version file not found at {VERSION_FILE}")
        sys.exit(1)

    # Get bump type from environment variable (default: patch)
    bump_type = os.environ.get('BUMP', 'patch').lower()
    valid_types = ['major', 'minor', 'patch']
    
    if bump_type not in valid_types:
        print(f"Warning: Invalid bump type '{bump_type}'. Defaulting to 'patch'.")
        bump_type = 'patch'

    content = VERSION_FILE.read_text()
    
    # Regex to find __version__ = "X.Y.Z"
    pattern = r'__version__\s*=\s*"(\d+)\.(\d+)\.(\d+)"'
    match = re.search(pattern, content)
    
    if not match:
        print(f"Error: Could not find valid version string in {VERSION_FILE}")
        sys.exit(1)

    major, minor, patch = map(int, match.groups())
    
    # Calculate new version
    if bump_type == 'major':
        major += 1
        minor = 0
        patch = 0
    elif bump_type == 'minor':
        minor += 1
        patch = 0
    else:  # patch
        patch += 1
        
    new_version = f"{major}.{minor}.{patch}"
    
    # Replace content
    new_content = re.sub(
        pattern,
        f'__version__ = "{new_version}"',
        content
    )
    
    VERSION_FILE.write_text(new_content)
    print(f"🚀 Bumped version ({bump_type}): {match.group(1)}.{match.group(2)}.{match.group(3)} -> {new_version}")

if __name__ == "__main__":
    try:
        bump_version()
    except Exception as e:
        print(f"Error bumping version: {e}")
        sys.exit(1)

2.2 The Basic Git Hook

Now, let's make it run automatically. Create a file at .git/hooks/post-commit and make it executable (chmod +x .git/hooks/post-commit):

#!/bin/bash
# Simple hook to bump version using BUMP env variable

# 1. Prevent infinite loops
if git show --name-only --format="" HEAD | grep -q "src/version.py"; then
    exit 0
fi

echo "🚀 Auto-bumping version..."

# 2. Run python script & Amend commit
# Note: Git doesn't pass env vars automatically, but if you run BUMP=minor git commit,
# it stays in the shell environment, so python sees it!
python3 scripts/bump_version.py

# 3. If python script succeeded (exit code 0), amend the commit
if [ $? -eq 0 ]; then
    git add src/version.py
    git commit --amend --no-verify --no-edit > /dev/null
    echo "✅ Commit amended with new version."
fi
exit 0

Step 3: Test It Out (Terminal)

Now try this in your terminal:

# Bump minor version (1.0.0 -> 1.1.0)
BUMP=minor git commit -m "feat: adding new login flow"

# Default bump (patch: 1.1.0 -> 1.1.1)
git commit -m "fix: typo in header"

It works! But wait, what if you use an IDE (VS Code, Cursor, Trae)? You can't easily pass BUMP=minor there.

Bonus: The Magic Trick (Part 2: IDE Users)

For IDE users, we want to control the version bump directly from the commit message.

Let's upgrade our hook to support tags like [minor] or [major] in the message.

Update your .git/hooks/post-commit file:

#!/bin/bash
# Advanced hook: Supports both BUMP env var AND commit message tags

# 1. Prevent infinite loops
if git show --name-only --format="" HEAD | grep -q "src/version.py"; then
    exit 0
fi

# 2. Get commit message
MSG=$(git log -1 --format=%B)

# 3. Determine bump type
# Check environment variable first (Terminal: BUMP=minor git commit ...)
if [[ -n "$BUMP" ]]; then
    BUMP_TYPE=$BUMP
# Check commit message tags (IDE: "fix bug [minor]")
elif [[ "$MSG" == *"[major]"* ]]; then
    BUMP_TYPE="major"
elif [[ "$MSG" == *"[minor]"* ]]; then
    BUMP_TYPE="minor"
elif [[ "$MSG" == *"[skip bump]"* ]]; then
    echo "⏩ Skipping version bump."
    exit 0
else
    BUMP_TYPE="patch"
fi

echo "🚀 Auto-bumping version ($BUMP_TYPE)..."

# 4. Run python script & Amend commit
BUMP=$BUMP_TYPE python3 scripts/bump_version.py

# 5. If python script succeeded, amend the commit
if [ $? -eq 0 ]; then
    git add src/version.py
    git commit --amend --no-verify --no-edit > /dev/null
    echo "✅ Commit amended with new version."
fi
exit 0

The Result? Pure Bliss.

Now, whether I'm in the terminal or using my IDE's Source Control panel, my workflow is seamless:

Terminal Power User: I want to bump minor version directly.
BUMP=minor git commit -m "Refactored login flow" -> minor bump (1.0.0 -> 1.1.0)
IDE User (or simple tag): I just want to tag it in the message.
git commit -m "Added dark mode support [minor]" -> minor bump (1.0.0 -> 1.1.0)
Standard update (Lazy mode): I commit normally without any flags.
git commit -m "Fixing header alignment" -> patch bump (1.0.0 -> 1.0.1)

I literally do zero extra work. My version numbers are always moving forward, tracking every single change I make.

Conclusion

Now there’s no way to forget versioning. You don’t need to keep thinking about version numbers either. You have better things to do.

Be lazy. Automate it. Your future self (and your users) will thank you.

What should happen when a webhook arrives twice?

Sun, 04 Oct 2026 20:17:31 +0000

An event notification looks like a neat starting point for automation. A form is submitted, a record changes, or another system announces that a job is ready. The first design question is often which AI action should follow. A more useful question is what should happen if the same event arrives again.

Relay App introduces webhooks and HTTP alongside AI actions, data transformations, and human review. Its current About page describes an independently operated site with source-attributed examples from original Relay.app material. Those examples can support a workflow design discussion. They do not establish the runtime guarantees of an integration, and no live webhook automation was executed for this article.

Decide what counts as one event

Imagine a form submission that should become a lead review draft. An illustrative workflow extracts the submitted fields, classifies the request, and presents a summary to a salesperson. Sending a second draft for the same submission would create confusion even if neither draft were automatically delivered to the prospect.

Start by choosing an event identity. A source-provided submission ID is often more useful than a timestamp. Write down whether an updated submission is a new event, a revision of the existing event, or something the process should ignore. That choice affects the data model and the review experience.

Do not assume that an arbitrary hash of the whole payload answers the question. A minor formatting change can produce a different hash for the same business event. Conversely, identical text can come from two separate requests. The identifier should represent the event you intend to process.

Separate receiving from acting

Receiving an event and completing its consequences are distinct moments. A workflow may acknowledge receipt, validate the payload, prepare a draft, and wait for review. Each step needs an observable outcome. A single completed flag hides too much when something fails in the middle.

Relay App's trigger descriptions include events sent by another service, while its AI sections explain extraction and classification. Together they suggest a useful planning sequence: establish the source, validate the data, then ask the model to perform a bounded task. Do not let the model infer missing identifiers that the receiving process requires.

Keep the original source reference beside the extracted fields. If a reviewer questions a classification, they need to inspect the input that produced it. A readable summary is useful, but it should not replace the event evidence needed to resolve a disagreement.

Treat uncertain delivery as its own problem

Suppose an approved draft should create a record in another system. The request times out after the destination accepts it. Retrying immediately might create a duplicate. Declaring failure might leave a valid result that the workflow cannot account for.

A proposed implementation can retain an operation ID, use an idempotency mechanism when the destination supports one, and inspect the external record when acknowledgement is uncertain. Those are engineering options to verify in the chosen service. They are not promises made by the homepage's webhook illustrations.

Before building, list which actions are harmless to repeat and which require a check. Re-reading a source and sending a customer message have different consequences. A retry policy should reflect the action, not simply apply the same number of attempts to every step.

Give the reviewer useful evidence

The site's human review examples distinguish approval, output review, and requests for information. A repeated event can require a different review decision from the original submission. Show the event ID, previous processing state, current draft, and reason for requesting another review.

For a practical test, send one example twice and compare the resulting artifacts. Then test a revised event with the same business identity. The expected outcome should be written before the run: one unchanged draft, a replacement draft awaiting fresh approval, or a visible exception.

A trigger is only the beginning of the process. A clear event identity and a plan for uncertain external actions make the rest of the design easier to discuss. Use the public workflow examples to draft that plan, then verify its behavior in the actual service before using real customer data.

How I Built an Autonomous B2B Directory Scraping & Enrichment Pipeline with n8n and Python

Sun, 04 Oct 2026 14:24:28 +0000

How I Built an Autonomous B2B Directory Scraping & Enrichment Pipeline with n8n and Python

Modern web scraping for B2B intelligence has shifted. Three years ago, a static requests session combined with BeautifulSoup was sufficient for extracting structured company profiles from most business directories. Today, client-side hydration (Next.js, Nuxt), dynamic fingerprinting, and complex pagination patterns cause naive scrapers to fail silently or stall out.

At the same time, commercial data vendors charge thousands of dollars a month for stale directory dumps that lack real-time enrichment. In this guide, we break down an enterprise-ready, decoupled architecture: a headless Python extraction engine orchestrated by n8n, complete with recursive pagination, schema validation via Pydantic, and multi-destination ingestion.

1. The Bottleneck: Why Traditional Pipelines Break

Scraping production directories typically breaks across three operational vectors:

DOM Hydration & Anti-Automation Fingerprints: Modern directory listings defer rendering contact cards and metadata until specific micro-interactions occur (scroll events, viewport visibility). Standard HTTP clients pull empty HTML shells.
Orchestration Coupling: Embedding proxy rotation, retry backoff, browser pools, and CRM export logic inside a single monolithic Python script creates unmaintainable code. A single unexpected DOM variation halts the entire batch.
Schema Drift & Data Quality: Unsanitized scraped fields (inconsistent international dialing codes, obfuscated mailto links, malformed URLs) corrupt downstream analytics and CRM pipelines.

The Solution

Decouple extraction from orchestration:

Headless Worker (Python / Playwright): Runs in an isolated container, handles stealth browser contexts, executes JavaScript micro-scrolls, and extracts raw data.
Orchestration & State Management (n8n): Handles rate-limiting queues, recursive pagination states, failure retries with exponential backoff, and webhook dispatching.
Data Integrity Layer (Pydantic): Enforces strict types, normalizes phone numbers to E.164, extracts naked domains, and validates emails before storage.

2. System Architecture

   +-------------------------------------------------------------+
   |                      n8n Orchestrator                       |
   |  [Trigger] -> [Queue / Pagination Loop] -> [Webhook Dispatch]|
   +--------------+-------------------------------+--------------+
                  | HTTP POST                     ^
                  v                               | Clean JSON
   +-------------------------------+              |
   |  Python FastAPI + Playwright  |              |
   |  - Stealth context init       |              |
   |  - Scroll hydration           |              |
   |  - DOM query extraction       |              |
   +--------------+----------------+              |
                  | Raw Objects                   |
                  v                               |
   +-------------------------------+              |
   |   Pydantic Validation Layer   |--------------+
   |  - RFC Email validation       |
   |  - E.164 Phone formatting     |
   |  - Domain sanitization        |
   +-------------------------------+

Queue Trigger: n8n pulls an unvisited directory page URL from a PostgreSQL queue or a configured array.
Browser Context Execution: n8n sends a payload to the internal Python FastAPI worker (/scrape endpoint).
Extraction & Normalization: Playwright runs headlessly, extracts targets, runs records through Pydantic validators, and returns a verified JSON array.
Database Routing & Sync: n8n deduplicates records against existing primary keys and concurrently writes to PostgreSQL, Airtable, or your target CRM.

3. The Code & Core Logic

Step A: The Playwright Stealth Scraper (Python)

This worker exposes a lightweight FastAPI endpoint. It leverages Playwright with realistic user-agent headers, evasive navigator properties, and automatic waiting for selector hydration.

# worker.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, HttpUrl
from playwright.async_api import async_playwright
import asyncio

app = FastAPI()

class ScrapeRequest(BaseModel):
    url: HttpUrl
    selector_container: str

@app.post("/extract")
async def extract_directory_page(payload: ScrapeRequest):
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=True,
            args=["--disable-blink-features=AutomationControlled", "--no-sandbox"]
        )
        context = await browser.new_context(
            user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
            viewport={"width": 1920, "height": 1080}
        )
        page = await context.new_page()
        
        try:
            await page.goto(str(payload.url), wait_until="networkidle", timeout=30000)
            
            # Trigger lazy loading by scrolling
            await page.evaluate("window.scrollTo(0, document.body.scrollHeight / 2);")
            await asyncio.sleep(1.2)
            await page.evaluate("window.scrollTo(0, document.body.scrollHeight);")
            await asyncio.sleep(1.0)
            
            cards = await page.query_selector_all(payload.selector_container)
            extracted = []
            
            for card in cards:
                name_el = await card.query_selector("h3.company-name")
                website_el = await card.query_selector("a.website-link")
                phone_el = await card.query_selector(".phone-display")
                
                extracted.append({
                    "raw_name": await name_el.inner_text() if name_el else None,
                    "raw_website": await website_el.get_attribute("href") if website_el else None,
                    "raw_phone": await phone_el.inner_text() if phone_el else None,
                })
                
            return {"status": "success", "total": len(extracted), "records": extracted}
        except Exception as e:
            raise HTTPException(status_code=500, detail=str(e))
        finally:
            await context.close()
            await browser.close()

Step B: Pydantic Validation & Normalization

Raw scraped data is notoriously messy. We enforce types and transform inputs into canonical shapes before the data reaches n8n:

# schemas.py
from pydantic import BaseModel, field_validator, HttpUrl
import re
from urllib.parse import urlparse

class CorporateRecord(BaseModel):
    company_name: str
    domain: str
    phone: str | None = None
    
    @field_validator("domain", mode="before")
    @classmethod
    def clean_domain(cls, v: str) -> str:
        if not v:
            raise ValueError("Empty website URL")
        v = v.strip().lower()
        if not v.startswith(("http://", "https://")):
            v = f"https://{v}"
        netloc = urlparse(v).netloc
        return netloc.replace("www.", "")

    @field_validator("phone", mode="before")
    @classmethod
    def normalize_phone(cls, v: str | None) -> str | None:
        if not v:
            return None
        digits = re.sub(r"[^\d+]", "", v)
        if len(digits) == 10 and not digits.startswith("+"):
            return f"+1{digits}"  # Standardize US numbers
        return digits if len(digits) >= 8 else None

Step C: n8n Dynamic Pagination & Deduplication Logic

In n8n, use a Code Node to manage state, calculate the next page offset, and filter out records that are already tracked in the database:

// n8n Code Node: Process Page Results & Generate Next Target
const response = $input.first().json;
const existingDomains = $('Check Existing Domains').all().map(item => item.json.domain);
const currentOffset = $node["Pagination Loop"].json.offset || 0;
const pageSize = 20;

// Deduplicate incoming batch against DB results
const validRecords = response.records.filter(record => {
  return record.domain && !existingDomains.includes(record.domain);
});

const hasMorePages = response.records.length === pageSize;

return {
  json: {
    validRecords: validRecords,
    nextOffset: currentOffset + pageSize,
    shouldContinue: hasMorePages,
    processedAt: new Date().toISOString()
  }
};

4. Deployment, Rate Limits, and Fault Tolerance

When running this architecture continuously, keep the following infrastructure practices in mind:

1. Handling Deadlocks & Stalled Instances

Playwright instances can occasionally freeze due to memory leaks on unhandled single-page apps. In Docker, configure strict container limits:

# docker-compose.yml snippet
services:
  playwright-worker:
    build: ./worker
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 2048M
    environment:
      - PYTHONUNBUFFERED=1

2. Exponential Backoff in n8n

Inside the n8n HTTP Request Node that calls the extraction worker:

Set Retry on Fail to true.
Set Max Tries to 3.
Set Wait Between Tries to 5000 ms with dynamic jitter to avoid burst patterns against the target directory.

3. CRM Rate-Limiting

CRMs like HubSpot and Salesforce enforce strict rate limits (e.g., 100 requests per 10 seconds). In n8n, insert a Split In Batches node set to batch sizes of 10, combined with a Wait node set to 1.5 seconds, ensuring pipeline compliance without dropping records.

5. Conclusion & Ready-to-Use Workflow

By decoupling the raw Playwright browser execution from the higher-level workflow orchestration in n8n, you get a clean, fault-tolerant B2B extraction engine that scales without requiring commercial SaaS subscriptions.

You can implement this architecture manually using the snippets above, or deploy our production-tested, turnkey package that includes pre-configured n8n JSON templates, Docker Compose files, stealth driver scripts, and Pydantic validation models:

Instant Access on Whop: Get the Pipeline Template
Direct Download on Gumroad: Download on Gumroad — use promo code EARLYBIRD for 20% off.

Building a Sub-Minute Cross-Platform Inventory Sync Engine with n8n, Shopify, WooCommerce & Airtable

Sat, 03 Oct 2026 21:09:22 +0000

Building a Sub-Minute Cross-Platform Inventory Sync Engine with n8n, Shopify, WooCommerce & Airtable

Dual-channel e-commerce sounds great on a slide deck until an order drops simultaneously on Shopify and WooCommerce for your last unit of inventory. Within 45 seconds, you've oversold, triggered a support ticket, and compromised a customer relationship.

Most teams reach for commercial integration platforms (Zapier, Celigo, or specialized multichannel SaaS tools). Then they discover the fine print: tiered pricing based on order volume, 15-minute polling windows on entry tiers, or brittle two-way connectors that enter infinite webhook loops the moment inventory changes bounce back and forth.

In this technical breakdown, we will walk through engineering a self-hosted, bidirectional inventory synchronization engine using n8n and Airtable as an immutable Single Source of Truth (SSOT). This setup achieves sub-minute delta propagation, completely eliminates infinite sync ping-pong, and runs on your own infrastructure for pennies a day.

1. The Bottleneck: Why Commercial Multi-Channel Sync Breaks

Commercial sync services rely on two flawed primitives:

High-Frequency Polling: Checking platform APIs every 5–15 minutes introduces a massive latency window where stockouts happen invisibly.
Direct Point-to-Point Webhooks: Triggering an inventory adjustment on Shopify when WooCommerce updates creates an immediate echo loop unless state is cleanly managed.

Shopify Order Placed -> Webhook to WooCommerce -> WooCommerce Stock Drops
                                  ^                               |
                                  |--- Webhook to Shopify fires --|

Without an atomic central state orchestrator, platform A and platform B trade fractional updates until API rate limits throttle both endpoints or your SKU balances hit negative values.

Furthermore, direct multi-point sync burns through Shopify's REST/GraphQL leaky bucket limits (40 requests/sec for Plus, 2 requests/sec for standard) and WooCommerce's REST bottlenecks on unoptimized WordPress MySQL instances.

To solve this, we design a hub-and-spoke pipeline with Airtable acting as the lock-manager and single source of truth.

2. Architecture: Hub-and-Spoke with Atomic Locking

[ Shopify Webhook ]     --> [ n8n Ingestion Node ]
                                     |
[ WooCommerce Webhook ] --> [ Delta Sanitization Node ]
                                     |
                            [ State Check in Airtable (SSOT) ]
                                     |
                        +------------+------------+
                        | Is Delta Actual & New? |
                        +------------+------------+
                                     |
                      YES            |            NO (Echo Loop)
                       |             +-------------> [ Drop / Log Event ]
                       v
        [ Update Airtable Master Record ]
                       |
       +---------------+---------------+
       |                               |
       v                               v
[ Push to Shopify API ]    [ Push to WooCommerce API ]
       |                               |
       +---------------+---------------+
                       |
               [ Audit / Alerting ]

Pipeline Flow:

Webhook Ingestion: Changes trigger on orders/create, inventory_levels/update (Shopify), and woocommerce_rest_insert_product_review or product.updated (WooCommerce).
Lock Verification & Hash Matching: We compute a state signature hash(SKU + New_Quantity + Timestamp_Window) and verify if this event was initiated by our own sync engine.
Airtable Reconciliation: Fetch the canonical record via SKU. Check if Target_Qty !== Current_Master_Qty.
Batched Downstream Fanout: Broadcast the new inventory levels to counterpart endpoints using rate-managed chunks.
Audit Trail: Write an execution ledger entry. If stock hits <= 0, dispatch an alert to Slack/Discord.

3. The Code & Logic: Loop Prevention and State Normalization

Step 1: Normalizing Webhook Payloads (n8n Code Node / JavaScript)

Incoming payloads from Shopify and WooCommerce have completely different data shapes. We normalize both down to a unified schema inside an n8n Code Node.

// Ingestion Normalizer Code Node
const items = $input.all();
const output = [];

for (const item of items) {
  const json = item.json;
  
  let normalized = {
    source: '',
    sku: '',
    newQuantity: 0,
    syncOriginatorId: null
  };
  
  // Check if Shopify Payload
  if (json.inventory_item_id || json.available !== undefined) {
    normalized.source = 'shopify';
    normalized.sku = json.sku || $('Extract_SKU').first().json.sku;
    normalized.newQuantity = parseInt(json.available, 10);
    // Custom metadata check to prevent loops
    normalized.syncOriginatorId = json.sync_token || null;
  }
  // Check if WooCommerce Payload
  else if (json.stock_quantity !== undefined) {
    normalized.source = 'woocommerce';
    normalized.sku = json.sku;
    normalized.newQuantity = parseInt(json.stock_quantity, 10);
    normalized.syncOriginatorId = json.meta_data?.find(m => m.key === '_sync_originator')?.value || null;
  }
  
  if (normalized.sku) {
    output.push({ json: normalized });
  }
}

return output;

Step 2: Preventing Webhook Echo Loops (Loop Breaker Logic)

To prevent ping-pong updates, we compare the incoming update against the current state stored in Airtable. If the delta is 0 or originated from our system's active lock token, the execution terminates immediately.

// Conflict Resolution & Loop Suppression Node
const input = $input.first().json;
const masterRecord = $('Fetch_Airtable_SKU').first().json;

const currentMasterStock = parseInt(masterRecord.fields['Master_Stock'], 10);
const incomingStock = input.newQuantity;
const lastSource = masterRecord.fields['Last_Sync_Source'];

// Condition 1: Zero-Delta check
if (incomingStock === currentMasterStock) {
  return [{ json: { execute: false, reason: 'Zero delta: State already synchronized.' } }];
}

// Condition 2: Circular update check
// If the change came from the platform we updated less than 15 seconds ago
const lastSyncTime = new Date(masterRecord.fields['Last_Sync_Timestamp']).getTime();
const timeDifferenceSeconds = (Date.now() - lastSyncTime) / 1000;

if (input.source === lastSource && timeDifferenceSeconds < 15) {
  return [{ json: { execute: false, reason: 'Circular echo caught: Update originated from active sync window.' } }];
}

// Passed all checks: Safe to broadcast
return [{
  json: {
    execute: true,
    sku: input.sku,
    stockToSet: incomingStock,
    originSource: input.source,
    airtableRecordId: masterRecord.id
  }
}];

Step 3: Shopify GraphQL Inventory Adjustment Payload

Instead of clunky REST endpoints, use Shopify's modern inventorySetOnHandQuantities mutation to update stock instantly with an idempotent reference ID:

mutation InventorySetOnHand($input: InventorySetOnHandQuantitiesInput!) {
  inventorySetOnHandQuantities(input: $input) {
    inventoryAdjustmentGroup {
      id
      createdAt
    }
    userErrors {
      field
      message
    }
  }
}

Variables passed dynamically by n8n:

{
  "input": {
    "reason": "correction",
    "referenceDocumentUri": "gid://n8n-sync/{{ $json.originSource }}-{{ $now.toMillis() }}",
    "setQuantities": [
      {
        "inventoryItemId": "gid://shopify/InventoryItem/{{ $json.shopifyInventoryItemId }}",
        "locationId": "gid://shopify/Location/{{ $json.shopifyLocationId }}",
        "quantity": {{ $json.stockToSet }}
      }
    ]
  }
}

4. Deployment, Rate Limiting & Fail-Safes

When syncing catalogs containing thousands of SKUs during peak events (Black Friday, flash sales), naive setups trigger HTTP 429 rate limits or execution queue lockups.

1. Batching & Throttling in n8n

Split In Batches Node: Route bulk updates through batches of 25 items.
Wait Node: Configure a 250ms buffer between calls to respect Shopify's 2 req/sec standard REST baseline (or higher for GraphQL buckets).
Exponential Backoff: In n8n's HTTP Request settings, activate Retry On Fail (up to 3 attempts) with a wait between tries of 1000ms.

2. Guarding Against Negative Inventory States

Miscalculations can sometimes push numbers below zero. In your Airtable validation node, insert an alert boundary:

if ($json.stockToSet < 0) {
  // Route execution to an alert path
  return [{ json: { error: true, alertType: 'NEGATIVE_STOCK_ALERT', sku: $json.sku, attemptedVal: $json.stockToSet } }];
}

Connect this branch directly to a Discord or Slack node to notify the operations team before an overselling disaster takes place.

5. Conclusion & Ready-to-Use Workflow

By placing an intelligent mediator (n8n + Airtable) between Shopify and WooCommerce, you get:

Sub-minute sync speeds (typically < 3.2 seconds end-to-end).
Zero recurrent per-order sync costs.
Full architectural control with comprehensive audit logs and circular loop protection.

You can manually build this workflow in your own n8n instance using the schemas, GraphQL payloads, and Code Node logic detailed in this guide.

If you prefer to skip the boilerplate, configuration headaches, and test fixture construction, you can download the production-ready package—complete with preconfigured JSON workflows, Airtable base schemas, and edge-case routing:

Instant Access on Whop
Direct Download on Gumroad — Use promo code EARLYBIRD for 20% off.

Have questions on handling specific channel edge-cases or complex variant mapping? Drop a comment below!

Building a Full-Stack Micro-SaaS Inside n8n: Serverless Web Apps, DataTables & AI Image Pipelines

Fri, 02 Oct 2026 20:38:57 +0000

Most developers treat n8n strictly as an orchestrator for backend APIs—triggering on webhooks, transforming JSON, and sending Slack alerts.

However, by pairing n8n's Webhook node with the Respond to Webhook node, you can turn n8n into a complete serverless full-stack web application host. No Vercel, no Next.js deployment, no Docker frontend containers required.

In this deep dive, we'll examine how we built an entire AI Virtual Staging Micro-SaaS that lives 100% inside an n8n workflow—including:

Serving an interactive, responsive SPA with embedded Before/After comparison sliders.
Performing client-side HTML5 Canvas compression to prevent payload timeouts.
Implementing non-blocking asynchronous job polling using native n8n DataTables.
Enforcing architectural prompt guards to freeze room geometry in image-to-image AI pipelines.

Figure 1: Production pipeline output — empty Berlin Altbau listing photo (left) transformed into curated luxury staging (right) in ~33 seconds on Google Gemini compute.

🏗️ The Serverless n8n Web App Architecture

┌────────────────────────────────────────────────────────┐
│                   CLIENT BROWSER                       │
│  - Vanilla JS SPA (Served directly by n8n)            │
│  - HTML5 Canvas client-side compression (<3MB)         │
│  - Interactive Before/After slider                     │
└────────────────────────────────────────────────────────┘
          │ (1) GET /webhook/home-staging-form
          ▼
┌────────────────────────────────────────────────────────┐
│            n8n Webhook: "Page HTML"                    │───► Sends raw text/html; charset=utf-8
└────────────────────────────────────────────────────────┘
          │ (2) POST /webhook/home-staging-submit
          ▼
┌────────────────────────────────────────────────────────┐
│     Access Gate & Honeypot Validation                  │───► Validates PIN & daily quota
└────────────────────────────────────────────────────────┘
          │ (3) Returns { "jobId": "..." } immediately (<200ms)
          ▼
┌────────────────────────────────────────────────────────┐
│   Async Job Pipeline (Brain -> Gemini -> Drive)        │───► Asynchronous execution
└────────────────────────────────────────────────────────┘
          │ (4) Client polls /home-staging-status?jobId=...
          ▼
┌────────────────────────────────────────────────────────┐
│      Status Node: Reads from n8n DataTable             │───► Status: 'pending' -> 'done'
└────────────────────────────────────────────────────────┘

Pattern 1: Serving Full-Stack HTML Directly via n8n

To serve an entire web app from n8n without external static hosting:

Create a Webhook node set to GET on /webhook/home-staging-form with Response Mode: When Last Node Finishes.
Connect a Code node (Page HTML) that returns your HTML, embedded CSS, and vanilla JS application as a template literal string:

// Inside 'Page HTML' Code Node
const BRAND = {
  name: "Studio AI",
  colorPrimary: "#133b5c",
  colorAccent: "#2a6f97"
};

const html = `<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>${BRAND.name}</title>
  <style>
    :root { --primary: ${BRAND.colorPrimary}; --accent: ${BRAND.colorAccent}; }
    body { font-family: system-ui, sans-serif; display: flex; justify-content: center; }
    /* Interactive Before/After Slider CSS */
    .cmp { position: relative; overflow: hidden; cursor: ew-resize; }
    .cmp .before { position: absolute; inset: 0; clip-path: inset(0 calc(100% - var(--pos, 50%)) 0 0); }
  </style>
</head>
<body>
  <div class="card">
    <h1>${BRAND.name}</h1>
    <form id="f">
      <input type="file" id="photo" accept="image/*">
      <button type="submit">Transform Room</button>
    </form>
  </div>
  <script>
    // Client-side execution logic...
  </script>
</body>
</html>`;

return [{ json: { html } }];

Connect a Respond to Webhook node with:
- Respond With: text
- Response Body: ={{ $json.html }}
- Header: Content-Type: text/html; charset=utf-8

When visitors navigate to your n8n webhook URL, n8n responds instantly with a full graphical interface.

Pattern 2: Client-Side Compression Before Webhook Submission

Raw smartphone photos from real estate agents frequently exceed 12 MB to 20 MB. Uploading raw payloads directly to an automation webhook risks gateway timeouts (504) or memory spikes in the n8n container.

We solve this entirely in the browser using HTML5 Canvas before FormData is dispatched:

async function compressImage(file) {
  const bmp = await createImageBitmap(file, { imageOrientation: 'from-image' });
  const MAX = 2048;
  const scale = Math.min(1, MAX / Math.max(bmp.width, bmp.height));
  
  if (scale >= 1 && file.size < 3 * 1024 * 1024) return file;
  
  const canvas = document.createElement('canvas');
  canvas.width = Math.round(bmp.width * scale);
  canvas.height = Math.round(bmp.height * scale);
  
  const ctx = canvas.getContext('2d');
  ctx.drawImage(bmp, 0, 0, canvas.width, canvas.height);
  
  const blob = await new Promise(res => canvas.toBlob(res, 'image/jpeg', 0.88));
  return new File([blob], 'photo.jpg', { type: 'image/jpeg' });
}

This reduces 15 MB iPhone photos to under 1.8 MB in under 200 milliseconds, eliminating upload failures.

Pattern 3: Asynchronous Job Polling via Native n8n DataTables

Synchronous image generation calls take 15 to 30 seconds. Keeping an HTTP connection open between the browser and n8n for 30 seconds is fragile (cellular disconnects, proxy timeouts).

Instead, we implement a two-phase asynchronous job queue using n8n's native DataTables:

Submission (POST /home-staging-submit):
- The webhook receives the image and parameters.
- Generates an unguessable jobId (crypto.randomUUID()).
- Inserts a row into the staging_jobs DataTable: status = "pending".
- Immediately returns { "jobId": "..." } to the client in <200ms.
Background Processing:
- The workflow continues downstream without blocking the client.
- Brain node builds the AI prompt.
- Google Gemini edits the photo.
- Result is saved to Google Drive.
- Updates the DataTable row: status = "done", driveFileId = "...".
Client Polling (GET /home-staging-status?jobId=...):
- The browser polls every 4 seconds.
- A tiny webhook reads the row from DataTable and returns { "status": "done" }.
- Once "done", the browser fetches the image from /home-staging-image?jobId=... and activates the interactive slider.

Pattern 4: Strict Architectural Prompt Engineering (The Camera Lock)

When working with image-to-image models (like Google Gemini 3 Pro Image / Nano Banana Pro), models often hallucinate extra windows, alter wall geometry, or shift the camera angle. In real estate, an edited room that changes the physical architecture is legally unusable.

To prevent this, every dynamic prompt ends with an immutable Camera Lock Rule:

const cameraLock = " [FINAL HARD CONSTRAINTS - VERIFY BEFORE OUTPUT]: " +
  "This is an in-place edit of the input photograph. " +
  "1) Camera position, angle, framing, perspective, and focal length must be PIXEL-IDENTICAL to the input photo. " +
  "2) Room geometry is FROZEN: same walls, same ceiling, same windows, same doors, same floor area - never extend or reproportion the room. " +
  "3) Do NOT add ceiling-mounted or architectural elements: no extra windows, no fireplaces, no moldings. " +
  "4) Added furniture and decor must fit entirely WITHIN the space visible in the original photo.";

Because image generation models place heavier attention weights on final tokens, this prompt structure guarantees architectural fidelity.

Conclusion & Production Workflow

By combining webhook-served HTML, client-side Canvas optimization, and native n8n DataTables for polling, you can build production-grade, full-stack Micro-SaaS tools inside a single n8n workspace.

🐙 View Architecture & Documentation on GitHub
📦 Get the Full Production Agency Kit on Gumroad | Whop Instant Access (Use code EARLYBIRD for 20% off)

Have you used n8n to serve client-facing frontend apps? Share your architecture in the comments below!

DevLog 20261002: Desktop Automation Toolbox and Mouse Emulation

Fri, 02 Oct 2026 15:16:32 +0000

DevLog 20261002: Desktop Automation Toolbox and Mouse Emulation

I remember when I used to use Macro Recorder to automate simple repetitive tasks — I especially liked its macro recording feature. It requires no programming and can easily get tedious jobs involving clicking and waiting done.

Since then, I've long moved past automating with basic mouse/keyboard emulation and have sunk deep into an API-driven approach — I just love how clean everything is when you can really program it. Well, that's a major reason why I started Divooka in the first place — lots of ecosystems and lots of tools we use are broken beyond repair and inherently NOT designed to be automated cleanly. MCP partly addressed that problem, but it's really just a modern remedy for mediocre design.

Either way, when I set out to implement procedural context for Divooka, desktop automation is nonetheless one of the first things that comes to mind. As we get more mature in OOP programming, generics, and recently achieved a true data structure algorithm implementation in Divooka, that is drawing closer.

In this short video, I show a desktop example for the automation toolbox that will come with the upcoming Divooka Explore. It's small, but it shows quite a few interesting things:

It creates a countdown GUI using the Immediate GUI framework.
It interacts with an opened window — in this case, the Paint program — through keyboard shortcuts and mouse input.
It can parse a stroke-based font at runtime and draw text with it.

If you ask me, that's a lot of cool features in such a small example! Really excited, and there's still more work to do, so see you soon!

How I Use Automation and Coding to Solve Everyday Problems

Fri, 02 Oct 2026 04:09:31 +0000

As an automation engineer who enjoys writing code, exploring new technologies, and finding smarter ways to solve everyday problems, I believe automation is about more than just writing scripts. It is about understanding how things work, identifying repetitive tasks, and finding practical ways to make those tasks faster, easier, and more reliable.

My interest in coding comes from curiosity. Whenever I see a task that requires the same steps to be repeated again and again, I start thinking about whether there is a way to automate it. Sometimes, a small script is enough to save time. Other times, the solution requires understanding a complete workflow, testing different approaches, and improving the code until everything works as expected.

How I Approach Automation in My Work

When I work on an automation task, I usually begin by understanding the problem. Before writing any code, I try to identify which steps are repetitive, where mistakes might happen, and what the expected result should look like.

For example, imagine a task that requires collecting information from multiple files, organizing the data, and preparing a report. Doing everything manually can take a lot of time, especially when the same process needs to be repeated daily.

Instead of performing every step by hand, I look for opportunities to use scripts that can process the information, organize the results, and generate the output automatically.

My general approach involves a few important steps:

Understand the problem: Identify the task, its requirements, and the result I want to achieve.

Plan the workflow: Break the process into smaller steps that are easier to understand and automate.

Write the code: Develop a script or program that handles the repetitive work.

Test the solution: Check whether the code produces the expected results and handles different situations.

Debug and improve: Find errors, fix problems, and make the solution more efficient and reliable.

This approach helps me focus on solving the actual problem instead of simply writing code without a clear purpose.

Turning Repetitive Tasks into Automated Workflows

One of the things I enjoy most about automation is seeing how a small piece of code can simplify a complicated process.

For example, automation can help with organizing files, processing spreadsheets, checking data, generating reports, sending notifications, or connecting different applications. These tasks may seem simple individually, but performing them manually every day can consume valuable time.

Using scripts and suitable tools, many of these processes can be handled automatically.

Python is particularly useful for this type of work because it offers libraries for file handling, data processing, APIs, and many other common automation tasks. Depending on the requirements, I can explore different tools and programming approaches to find a solution that fits the problem.

However, I also understand that automation is not always about removing every human step. Some tasks still require human review, especially when decisions depend on context or when the results need to be verified. My goal is to automate the repetitive parts while keeping the overall process understandable and dependable.

The Challenges I Face While Coding

Automation does not always work perfectly on the first attempt. Sometimes, a script fails because the input data has an unexpected format. In other cases, an API returns an error, a website changes its structure, or a process behaves differently than expected.

These situations are a normal part of software development.

When something goes wrong, I try to understand the reason instead of simply changing the code until the error disappears. I check error messages, examine the data, test individual functions, and make changes step by step.

I also pay attention to edge cases. A script that works with one example may fail when it encounters an empty file, missing values, duplicate records, or an unexpected response.

Learning to handle these situations is an important part of building reliable automation.

For me, debugging is not just about fixing errors. It is an opportunity to understand the system better and improve the quality of my work.

Learning New Technologies Through Practical Projects

Technology continues to evolve, and there is always something new to explore. I enjoy experimenting with programming tools, automation frameworks, APIs, and other technologies that can help solve practical problems.

Rather than learning everything only through theory, I prefer applying new concepts to small projects. Building something gives me a clearer understanding of how the different parts work together.

A simple project might involve automating a spreadsheet, creating a script to organize files, connecting two applications through an API, or developing a tool that reduces manual data entry.

Even when a project does not work as expected, the experience helps me learn something valuable.

I believe developers grow through continuous practice. Every project introduces new challenges, and every challenge creates an opportunity to improve problem-solving skills.

How I Make Automation More Reliable

Writing a script that works once is one thing. Creating an automation process that continues to work correctly is another.

I try to think beyond the initial result and consider what might happen when the script encounters an error, receives unexpected input, or runs multiple times.

Some important practices include:

Using clear and maintainable code.

Validating input data before processing it.

Handling exceptions and recording useful error messages.

Testing the workflow with different inputs.

Avoiding unnecessary complexity.

Reviewing the results to make sure the automation is doing the intended job.

These practices help make automation easier to understand, maintain, and improve over time.

I also believe that a useful automation solution should be practical. A complicated system is not always better than a simple script. The right solution depends on the problem, the available tools, and the needs of the people using it.

My Experience and What I Want to Learn Next

My interest in automation and coding continues to motivate me to experiment, build small projects, and discover more efficient ways to work. I enjoy the process of taking an idea, breaking it down into manageable steps, and turning it into something useful.

I also recognize that learning never really stops in technology. There are always new tools to explore, better coding practices to discover, and different approaches to solving familiar problems.

Going forward, I want to continue improving my programming skills, exploring modern automation techniques, and building projects that address real-world challenges. I am particularly interested in understanding how different technologies can work together to create smoother workflows and reduce unnecessary manual effort.

For me, the most rewarding part of coding is not simply seeing a script run successfully. It is knowing that the solution serves a purpose, saves time, or makes someone's work a little easier.

Final Thoughts

Being an automation engineer means approaching everyday tasks with curiosity and looking for opportunities to improve the way things work. It requires patience, logical thinking, experimentation, and a willingness to learn from mistakes.

I do not believe every problem needs a complicated technical solution. Sometimes, the smallest improvement can make the biggest practical difference.

My goal is to keep learning, keep experimenting, and keep turning ideas into useful solutions through code and automation.

I would also love to hear from other developers and automation engineers: What is one repetitive task you have automated with code, and how did it change the way you work?

Let's share ideas, learn from each other's experiences, and discover new ways to make everyday work more efficient.

How I Use Python in My Development Workflow

Thu, 01 Oct 2026 11:17:07 +0000

As a Full Stack Developer, I believe learning new technologies helps me solve problems in different ways. Along with C#, .NET Core, SQL Server, and Angular, Python is another useful language for backend development, automation, and simplifying repetitive tasks.

I use Python to explore ways to automate everyday work, process data, build scripts, and connect different tools through APIs. Sometimes, a small Python script can save time by handling a task that would otherwise require repetitive manual effort.

What I Find Interesting About Python

Python has a readable syntax, a large ecosystem of libraries, and many practical applications. It can be used for web development, data processing, testing, and automation. I also find it useful when experimenting with new ideas or creating small tools to solve specific problems.

How Python Fits into My Development Work

When working on web applications, I think about how different technologies can work together. For example, a .NET application can handle core business logic while a Python script processes data or automates a separate workflow. REST APIs can help connect these components when needed.

Of course, choosing the right technology depends on the project requirements. I don't believe every problem needs a new language or framework. Sometimes, improving the existing code is the simplest solution.

My Learning Mindset

For me, software development is about more than mastering one programming language. It's about understanding problems, exploring possible solutions, and choosing tools that make the work more efficient and maintainable.

I'm interested in learning how other developers use Python in their everyday workflows.

How do you use Python in your projects? Do you mainly use it for automation, backend development, data processing, or something else?

Choosing the Right Laboratory Software for a Modern Diagnostic Lab

Wed, 30 Sep 2026 05:48:40 +0000

Today's diagnostic laboratories are far more than test samples and reports. Every test result is supported by a chain of activities including patient registration, sample collection, barcode identification, test processing, quality checks, report validation, billing, communication and record management. Even a well-run lab can still have delays, errors and increasing administrative pressure if these processes are done manually or with disconnected systems.

Here is where laboratory software comes into the picture.

The right laboratory management system can bring together disparate functions, improve visibility across operations and enable laboratories to produce reports more effectively without sacrificing accuracy. But selecting the right system isn’t just about choosing the software with the longest list of features. It’s about understanding what the lab actually needs, and finding a platform that can support those needs as the business grows.

So, functionality, reliability, usability and scalability should be the starting point for laboratories looking for best laboratory software in India rather than promotional claims.

What is Laboratory Software and Why Does a Diagnostic Laboratory Need it?

What is laboratory software? It is a digital system that handles and organizes the different processes of diagnostic testing. It can integrate patient registration, sample management, test allocation, result entry, report generation, billing and other laboratory operations in a single workflow.

In a traditional setup information can go through registries, spreadsheets, paper forms, messaging applications and separate billing systems. Each additional handoff is another opportunity for information to be entered incorrectly, misplaced or delayed.

Laboratory software gives a structured digital workflow that reduces the need for manual processes.

For a diagnostic centre with a low number of tests performed per day, manual processes might seem to be under control at first. But with more and more patients, additional departments or the introduction of collection centres, it becomes increasingly difficult to maintain the same workflow.

This is especially the case for pathology laboratories where the transfer of a sample and the accuracy of the patient information attached to it must be traceable through the testing process.

Pathology Lab Software in India – What to Look For?

Although the needs of each laboratory are unique, a few capabilities have become increasingly vital to the modern diagnostic operation.

A good pathology lab software in India should ease the process from patient registration to final report delivery. Patient information must be captured accurately, samples identifiable throughout their life cycle and authorized personnel should be able to access relevant information without unnecessary delays.

Another important consideration is sample tracking. When a sample arrives in the laboratory, staff should be able to track the status and location of the sample in the testing workflow. Using barcodes for identification can cut down on manual entry and improve traceability, especially in labs that process many samples.

Generation of reports is equally important. Laboratories need systems that can consolidate test results in a structured way and allow for proper validation and approval workflows. The goal is not to get a report out faster. It’s to put in place a process that reduces needless errors and creates a more consistent reporting cycle.

Integration is something else to think about. A laboratory rarely operates alone. It may have to talk to analysers, billing systems, hospital systems, collection centres or other digital platforms. The right software with integration capabilities can reduce repetitive data entry and create a more connected laboratory environment.

How Laboratory Management Software Improves Efficiency?

One of the biggest benefits of laboratory management software is its capacity to reduce repetitive admin work.

Let’s say a patient needs to undergo a series of tests at a diagnostic centre. In a manual environment, details may have to be entered more than once during registration, billing, sample collection and reporting. Having connected software workflow means that relevant information can flow through the process without the staff having to recreate it at each step.

That’s a time saver, but the advantage is more than speed.

Reducing repetitive data entry can also lower the risk of transcription errors. This allows staff more time to focus on activities that require professional judgment and laboratory expertise.

A centralized system can also make things more visible. Laboratory Managers get a better view of pending tests, completed reports, workload and operational activity. This assists in identifying bottlenecks and correcting them before they impact patient service.

For growing laboratories, these efficiencies can be especially valuable because an increase in patient volume does not need to mean a proportionate increase in administrative workload.

Importance of Report Automation in Diagnostic Labs

Reporting is one of the more visible aspects of a laboratory’s service. The report is the result of the whole diagnostic process for patients and referring doctors.

A laboratory software system can help to standardize report formats, automate repetitive reporting tasks and facilitate appropriate validation workflows. This can help to increase uniformity in the reporting process and decrease reliance on manual preparation.

Automated reporting may also be useful in laboratories that do large numbers of routine investigations. To avoid repeating the same report structures over and over, predefined formats can be helpful.

But automation should not be a substitute for professional judgment. Laboratory results must still be properly reviewed and validated by authorized personnel. The role of technology is to make the workflow more organized and efficient, not to replace professional responsibility.

Data management and security are equally important

Laboratory software is used to manage sensitive information on patients and diagnostics. This means that security should be considered together with functionality.

A laboratory needs to understand how patient information is stored, who can access it, and how access is controlled. Labs can better control sensitive information with user permissions, authentication mechanisms, audit trails and appropriate data protection practices.

Another important consideration is data availability. A system that enables authorized users to quickly locate relevant information can facilitate smoother laboratory operations, particularly in a laboratory with multiple departments or collection centres.

Depending upon system architecture and organizational requirements they can also offer more flexibility in allowing authorized users to access the system from different locations. This can be a large consideration for laboratories looking to expand their operations.

What is the Best Laboratory Management Software in India?

No single software platform will be the right fit for every laboratory. What’s the best laboratory management software in India for one organization might not be the best for another.

The right system should integrate with the laboratory’s workflow, not require the staff to constantly work around the software.

So, usability is important. A technically powerful system can become a burden if employees need a lot of training for routine tasks. The interface should be intuitive so that different users can understand what they need to do and can efficiently complete common processes.

Scalability matters, too. A small diagnostic centre can start with a single site and a limited test menu, but it can grow to include collection centres, departments or larger sample volumes. The software needs to be able to support that growth without the organization having to completely rebuild its technology infrastructure.

Another factor not to be ignored is dependable support. The laboratory software is integrated into the operational backbone of the diagnostics centre. When things go wrong, prompt technical help can be as important as the features in the software.

The decision should therefore be made on more than a comparison of feature lists. Laboratories should weigh workflow compatibility, integration capabilities, reporting requirements, security, scalability, usability and ongoing support when making a selection.

Is Pathology Software Only Useful for Large Laboratories?

Not necessarily.

While larger laboratories have more complex workflows and higher throughput, smaller diagnostic facilities can also benefit from structured digital processes. Getting the right software in place early can actually make it easier for a lab to establish consistent workflows as it grows.

The trick is to pick a system that satisfies your current needs, but doesn’t limit your growth down the road.

For laboratories seeking the best pathology software in India, this means not just considering the size of the organization. A more useful question is whether the software can manage the operational issues of the laboratory today, but still be able to support the needs of tomorrow.

How can technology enhance the patient experience?

The impact of laboratory software doesn’t end with the laboratory’s internal team.

Patients are wanting more and more for diagnostic services that are convenient, transparent and responsive. You can get a smoother experience with faster registration, organized sample processing and timely report delivery.

Digital workflows can also cut down on unnecessary waiting and repetitive paperwork. “Where information flows easily between the different parts of the diagnostic journey, staff can spend less time looking for records, or moving information manually.

Timely, well formatted reports can also facilitate communication for referring physicians.

The conclusion is that lab technology should be designed to make it easier for labs to manage information and processes so that health care providers can focus on providing reliable diagnostic services.

ItHealth: ONE DIGITAL LABORATORY WORKFLOW

ItHealth is a cloud-based laboratory information management platform that allows diagnostic laboratories to manage key laboratory processes in a connected digital environment. It includes features related to patient and sample management, automated reporting, workflow management and laboratory operations to help laboratories reduce their dependence on disconnected manual processes. One of the options for organizations looking at laboratory technology is ItHealth, with a system that integrates operational management with digital reporting and a scalable cloud-based approach.

Selecting Lab Software Is a Long-Term Decision

Don’t treat choosing laboratory software as a short-term technology purchase. That’s a decision that could impact how a lab manages information, how it coordinates its teams and how it serves patients for years to come.

An effective system can reduce repetitive work, improve sample tracking, streamline reporting and give lab managers a better picture of daily operations. But these benefits are contingent on choosing a technology that truly matches the needs of the laboratory.

Prior to selecting a solution, laboratories should assess their current workflow, identify where delays or errors are happening and determine which processes should be further automated. Then they should evaluate software based on usability, integration, scalability, security, reporting capabilities and support, instead of just a list of features or marketing claims.

Summary: Build a Smarter Laboratory Workflow

Diagnostic laboratories are faced with more information, higher patient expectations and increasingly complex operational requirements. As the lab expands, relying on fragmented manual processes can make it more difficult to maintain efficiency.

With the right lab software, you are able to establish more structured pathway from patient registration and specimen collection to testing, verification and reporting. It can reduce repetitive work, increase traceability and give lab teams greater control of their day-to-day operations.

Whether you are a standalone pathology centre, a growing diagnostic chain or part of a larger healthcare organization, the aim should be the same, invest in technology which makes your workflow simpler, more reliable and ready for the future.

If you’re ready to move beyond fragmented processes and create a more connected digital workflow for your laboratory, explore ItHealth by Imbibe Technologies and discover how a cloud-based laboratory information management platform can help streamline laboratory operations, simplify reporting and support a more efficient diagnostic workflow. Take the next step towards a smarter, more connected laboratory with ItHealth.

Jev & computer-use

Tue, 29 Sep 2026 14:14:02 +0000

Current work: jev-computer-use

My TL for the last few days has been taken over by Jev, a system one model from typesafe.ai. So i applied for the waitlist and got in.

To me a interesting use-case for this kind of model is on browser/computer-use, lot of decision to be taken which may not need long reasoning before doing so, the UX improves with the speed we get and automations feel right.
Checkout the jev-ultrafast by browser-use.

Take a general purpose model (GPT / Claude), the lifecycle of a understand user request looks like:

plan
generate code / text
produce tool calls
something broke / unexpected ? - give the agent new state ask it to redo stuff.

This is useful when the task isn't fully known in advance, involves long reasoning and time. But think of structured inputs like forms or OS accessibility, the decisions of what needs be done given a goal is more local than you think.

What is Jev?

This could be very simply put as a classifier. The model accepts a state and questions returns a typed decision. A state is your structured text input and questions have three primitives:

Choice: picks one of the options you provide + confidence
Score: rate something you provide + confidence
Noul: yes / no with a probability

General purpose LLMs are also capable of it but the main difference here is - jev exposes a decision interface rather text generation interface, give the context and decision to make, received a typed result.

Think of making your agent logic as state machines, give that state, goal and the choices it can trigger, this works really well.

On computer-use

There are multiple ways to do this:

Screenshot, use a model for segmenting and OCR then convert to structured format pass it to JEV for decision
OR the OS itself provides accessibility APIs to navigate, its already structured use it directly

I'm currently experimenting on this: jev-computer-use

A example computer-use flow:

Claims and things to look out for

Although the model is refreshing in the age of LLMs, i think the magic lies in the data, they do claim they are a data research company first and it's been trained on 100% synthetic data.

There is one more strong claim on almost no hallucination, being type safe does not guarantee that.
If you think this run deterministically, NO, same prompt gives you different probabilities every run.

Confidence score is a derived metric which is tightly coupled with the classification scores. So it may not be the right measure for whatever you are doing and you are are open to come up with any definition for the confidence using the probabilities list.

QAlity: The AI-Powered No-Code Test Automation Platform Built for Modern QA Teams

Tue, 29 Sep 2026 10:39:10 +0000

Software is moving faster than ever.

New features are released every day. User journeys are becoming more complex. And QA teams are expected to deliver reliable releases without slowing development down.
But testing hasn't become simpler.

Manual regression testing can be repetitive and time-consuming, while traditional automation often comes with its own challenges - writing scripts, maintaining selectors, fixing failed tests, and constantly updating automation as applications evolve.

What if creating automated tests didn't have to be complicated?

That's where comes in.

Meet QAlity

QAlity is an AI-powered, no-code test automation platform built for modern QA teams.
It helps teams move from manual testing to automated testing without making every workflow dependent on code.

With QAlity, teams can:

Create and organize test cases
Record real user interactions
Turn workflows into automated tests
Use AI to assist with test creation
Run tests in the cloud
Test both UI workflows and APIs
Build test plans and manage executions
Review results and execution history

One platform. One testing workflow. Less complexity.

Think about a typical testing scenario.

A tester needs to verify a login flow, search for a product, add it to the cart, and complete checkout.
Traditionally, automating this workflow could mean writing scripts, identifying selectors, handling waits, and maintaining the test whenever the application changes.

With QAlity, the process starts with the tester simply using the application.

Record the workflow.
Turn it into a test.
Run it again whenever you need it.
No need to write automation code for every interaction.

This makes it easier to turn repetitive manual scenarios into reusable
automated tests and gives QA teams more time to focus on testing what
actually matters.

AI That Works With Your Tests

Automation isn't only about recording clicks.

Modern applications change constantly, and QA teams need to create, update, and maintain tests just as quickly.

QAlity brings AI into the testing workflow to help testers work faster.

AI-assisted capabilities can help with test-step creation and refinement, while Auto-Heal Recovery is designed to help automated tests handle certain application changes.

The idea is simple:
Less time fixing automation. More time testing the product.

More Than UI Testing

Modern applications don't stop at the browser.

Behind every button, form, and checkout page are APIs and backend services that make the application work.

QAlity supports both sides of the equation.

UI Testing
Automate real user workflows and validate the experience from the front end.

API Testing
Test the APIs powering your application and validate backend behavior.

Regression Testing
Run reusable automated tests whenever your application changes.

Test Plans
Bring related test cases together and execute them as structured testing cycles.

This means teams can move beyond individual automated scripts and build a more complete testing strategy.

From Test Case to Test Result

Creating a test is only the beginning.

QA teams also need to know what was tested, when it was executed, what passed, what failed, and how results change over time.

QAlity connects these pieces together:
Test Cases → Test Plans → Execution → Results → Reports

Instead of jumping between different tools and disconnected workflows, teams can manage their testing process from one place.

And when it's time for the next release?
Run it again.

Your automated tests become reusable assets rather than one-time testing efforts.

Built for Modern QA Teams

QAlity is designed for teams at different stages of their automation journey.

Whether you're a:

Manual tester looking to automate repetitive workflows
QA engineer building regression coverage
Automation team managing larger test suites
Developer validating application workflows
SaaS team testing continuously changing products

…the goal remains the same:

Make testing faster without making it more complicated.

Why QAlity?

QAlity brings together the capabilities modern QA teams need:

No-Code Automation
Create automated workflows without writing scripts for every interaction.

AI-Assisted Testing
Use AI to accelerate test creation and reduce repetitive work.

Auto-Heal Recovery
Help automated tests adapt to certain application changes.

Cloud Execution
Run automated tests without relying entirely on local environments.

UI + API Testing
Test both the user experience and the APIs behind it.

Test Management & Reporting
Organize test cases, plans, executions, and results in one workspace.

The Bigger Idea

Test automation shouldn't become another system your QA team spends more time maintaining than using.

It should make testing repeatable, scalable, and easier to manage.

That's what QAlity is built around.
AI-powered assistance.
No-code automation.
Connected testing workflows.
Less repetitive work.

As development cycles continue to accelerate, QA needs to keep pace.

QAlity helps teams build, automate, execute, and manage tests - so they can spend less time maintaining automation and more time delivering quality software.

Build. Automate. Execute. Ship with confidence.

Ready to rethink your testing workflow?
\[Explore QAlity →\]

Building for the Person Who Can't Debug It

Thu, 24 Sep 2026 13:19:38 +0000

This is the second half of a two-part writeup on an n8n lead-intake workflow.
Part1 covered the Webhook payload break — this one covers the rest of the build.

The first post about this workflow covered the Webhook payload break — the moment the Form Trigger got swapped out and every downstream reference silently pointed at data that no longer existed. That part's done. This is the rest of the build: three smaller decisions that don't share a bug, but do share a reason.

Marisol — the client this workflow was built for — isn't technical. She has no developer on call. If this breaks while she's using it, she's the one looking at it first. That fact didn't come up once and get filed away; it kept showing up, in places that had nothing to do with each other.

Flipping the IF Node

The junk filter was supposed to do one thing: stop a submission if both phone and email were empty, since a lead with neither is useless. The logic in my head was straightforward — "if phone empty AND email empty, stop."

But when I actually built the IF node, I flipped it: "if phone OR email is not empty, continue." Same condition, inverted. What changed was which branch reads as the main path. Written this way, the true branch is the branch I actually follow when I trace the workflow — the valid data moving forward. The false branch is just "nothing happens," which is exactly what it should look like: the door that quietly doesn't open.

It's a small thing. The workflow does the same job either way. But if Marisol — or anyone else — ever opens this node to understand why a lead didn't show up in Sheets, the condition should read like the thing that's actually happening, not like a double negative she has to mentally invert first.

Tested both directions: a submission with both phone and email empty correctly stopped, and a submission with just one filled correctly passed through.

Redesigning the Set Node

Originally, the Set node had exactly one job — default the message field to "No message provided" if it came in empty. That was true right up until the trigger swap.

Once the Webhook replaced the Form Trigger, the payload picked up a lot of extra weight — headers, params, webhookUrl, executionMode, all the raw HTTP metadata that comes bundled with a webhook request. None of it was useful to Sheets or Slack. All of it was now sitting in the same object as the five fields that actually mattered.

I could have left it. The extra keys wouldn't have broken anything downstream — Sheets and Slack only read what I told them to read. But that's exactly the kind of thing that's invisible until someone else has to look at it. So I rebuilt the Set node to do more: explicit mappings for all five clean fields — Name, Phone, Email, Service address, Message — stripping the noise and defaulting the message in the same place.

I chose explicit field mappings over n8n's "keep only set fields" toggle on purpose. The toggle does the same job with less typing, but it hides what's happening — you'd have to open the node and go find the setting to know why the extra fields disappeared. Written out explicitly, the five fields the workflow actually cares about are right there, visible, nothing to go dig for.

Writing the Doc for Marisol

The last piece was the plain-English explanation — the thing Marisol actually reads if something goes wrong. First time writing a doc like this, so I built it around what she'd need, not around what I found interesting to explain: what the workflow does, a step-by-step walkthrough using the real node names (Filter Out Junk Leads, Clean and Format Lead Data — the names she'd see if she ever opened it herself), and a troubleshooting section.

For troubleshooting, I didn't invent hypothetical failure cases — I used one that had actually happened. During testing, the Google Sheets node failed once because the credential needed reconnecting; disconnecting and reconnecting it fixed it. Small thing, but real, and more likely to recur than something exotic I could've made up instead.

The doc and the exported workflow JSON stayed as two separate files, deliberately. The JSON is the actual automation, importable straight into her n8n. The doc is a reference for a human. They don't get merged into each other — that split is what the brief asked for, and forcing them together would've made one file try to do two jobs.

Same Constraint, Three Places

None of these three decisions are related on the surface — an inverted condition, a redesigned node, a document. What ties them together is that each one got shaped by a person who wasn't going to be in the room the next time this workflow needed explaining, and who can't reason through n8n's internals if it breaks. The workflow doesn't get simpler because of that. It gets more legible.

More on how this and other builds come together: tarek-elzoghby.github.io/tarek-elzoghby-hub

What Really Happens When AI Makes a Decision?

Wed, 23 Sep 2026 04:43:26 +0000

Today I was reading about Jev, and one idea genuinely stopped me.

We usually think about AI inference in a very familiar way:

Prompt → generate tokens → get an answer.

But what if the model doesn't need to generate an answer at all?

What if the output isn't a paragraph, an explanation, or even a piece of JSON?

What if the output is simply the decision?

That's what I found interesting about Jev.

Instead of thinking about inference as:

Input → Generate text → Parse the response → Extract the decision

Jev's decision-oriented approach can be thought of as:

Input → Make a decision → Return the probability

And that sounds like a small difference until you start thinking about where this could actually be useful.

Imagine a testing system processing thousands of test failures.

Instead of asking an LLM:

"Analyze this failure and explain whether this is a regression."

you could think about the actual decision the system needs:

Is this a real regression? → 94%

Should this test be retried? → 8%

Does this need human review? → 91%

The model isn't writing an explanation and leaving the application to figure out what it meant.

The decision itself becomes the output.

That distinction got me thinking about how often we use generative AI for problems that aren't really generative problems.

A QA system doesn't necessarily need an essay about a failed test.

A fraud detection system doesn't need a paragraph explaining every transaction.

A monitoring system doesn't need a beautifully written response every time an anomaly appears.

Sometimes the software just needs a decision.

And this is where Jev's three basic decision types become interesting:

Choice → choose between options

Score → assign a numerical score

Noul → make a true/false type decision

These sound simple, but they map surprisingly well to the kinds of decisions software makes constantly.

Which category does this belong to?

How relevant is this?

Should this be retried?

Is this suspicious?

Does this need human intervention?

Which route should this request take?

In many of these cases, natural language isn't actually the final product.

The decision is.

But then I came across the part I found even more interesting: probability.

It's easy for a model to say:

"I'm 80% confident."

But the interesting question isn't whether the model can produce the number 0.8.

The interesting question is whether that 0.8 actually means something.

This is where calibration comes in.

If a model makes a large number of predictions with an estimated probability of 80%, then a well-calibrated system should be correct on roughly 80% of those cases.

So probability becomes more than a confidence label.

It becomes a signal that the rest of the system can use.

Imagine an automated QA workflow:

A test failure gets a 97% regression probability.

Another gets 61%.

Another gets 12%.

Those aren't just three predictions. They can represent three different levels of certainty, which means the software can potentially treat them differently.

High-confidence decisions can be automated.

Uncertain decisions can be routed for human review.

Low-confidence decisions can be ignored or handled differently.

The exact thresholds depend on the application, but the important part is that uncertainty becomes part of the interface between the model and the software.

And then I started thinking about something else.

Even when we ask an LLM to return structured JSON, we're still using a generative model to produce that structure.

For example:

{
"is_regression": true,
"confidence": 0.94
}

It looks like a structured decision to us.

But the model still generates the tokens that make up that JSON. The application receives that generated output and then parses it to extract the fields it actually needs.

So even though we've constrained the output format, the underlying interaction is still fundamentally generative.

That's what makes the decision-oriented approach interesting to me.

The question changes from:

"What should the model generate?"

to:

"What decision does the application need?"

And that's a much more interesting way to think about AI inference for certain types of systems.

Not every AI problem is a content-generation problem.

Sometimes the model doesn't need to write.

It needs to classify.

It needs to choose.

It needs to score.

It needs to say yes or no.

And ideally, it needs to tell the system how certain that decision is.

The more I thought about it, the more use cases started coming to mind: QA, fraud detection, anomaly monitoring, routing, ranking, classification, moderation, and pretty much any workflow where the final consumer of the model's output is another piece of software rather than a human reading a response.

That led me to a very simple way of thinking about the difference:

LLMs → Generate

Jev → Decide

Of course, LLMs can also be used for classification and decision-making, so the distinction isn't that simple technically.

What I found interesting is the abstraction.

We're so used to thinking about AI as something that talks to us.

Jev made me think about AI as something that can simply make a decision for a system.

And honestly, I hadn't thought about AI inference from that angle before.

Maybe AI doesn't always need to talk.

Sometimes, you just need it to decide.

Where To Draw The Line Between A Workflow And An Agent

Tue, 22 Sep 2026 12:59:47 +0000

A lot of the agent threads here land in the same argument, so here is the split that has held up for me across a few production systems. Curious whether it matches what other people on CoderLegion have run into.

The Line Itself

A workflow runs a path you drew. Every branch, every condition, every fallback exists because someone anticipated it at design time. An agent decides the next step at runtime from a goal and a set of tools.

That gives you a rule you can actually apply: name the steps you can name, and let an agent handle the ones you can only describe.

Invoice matching against a purchase order is nameable. Triaging a free text support ticket into the right queue is describable. Most real systems end up as a workflow with one or two agent shaped holes in it, not as one or the other. I keep the longer version of that split, the agent side, the workflow side, and where the two meet, in this guide to AI automation.

Where Agent Only Designs Fall Over

Handing the whole process to an agent feels clean until you have to explain a decision to somebody. Fixed paths are inspectable. You can diff them, test them, and point at the branch that fired. An agent's reasoning is not a diff.

So the parts that are regulated, audited, or expensive to get wrong stay as explicit steps, even when the agent could technically handle them.

Where Workflow Only Designs Fall Over

The opposite failure is the workflow that grows a new branch every time reality surprises it. If your automation has forty conditions and half of them fire once a month, you have built a bad classifier out of if statements. That is exactly where an agent earns its cost.

Three Things That Decide Whether The Agent Half Survives

Boundaries. The agent gets the smallest tool set that lets it finish, not your whole API surface.

A confidence threshold. Below it the agent routes to a human instead of guessing. That single rule prevents most of the incidents people blame on agents.

Memory of outcomes. If nothing records that an action worked or failed, the system cannot improve, and you are paying a lot for a random number generator.

Takeaway

Do not start by converting your most complex process. Take a high volume, low blast radius one, get the escalation path working, then widen.

What is the messiest workflow you have seen that should have been an agent, or the other way around?

A scraper isn’t a monitor: detecting new Telegram posts with Apify and n8n

Tue, 22 Sep 2026 02:46:31 +0000

My Actor run succeeded. It returned five recent Telegram posts, each with an ID, timestamp, and permalink.

Then I asked the question the automation actually needed to answer:

Which posts are new?

The honest answer was: the current run cannot know by itself.

Nothing had failed. The Actor had done its job. It had retrieved what was visible now. But “new” is not a property contained in one snapshot; it is the difference between the current snapshot and a previous one.

That distinction is the difference between a scraper that runs on a schedule and a monitor you can trust.

In this tutorial, I’ll show the state layer I added around an Apify Actor:

a stable identity for every record;
state partitioned by Telegram channel;
a deliberate first-run policy;
duplicate prevention across executions;
a warning when the polling window may be too small; and
fail-closed handling for missing or malformed state.

The same design works for price trackers, job monitors, lead feeds, inventory checks, and any other workflow that repeatedly asks, “What changed?”

Implementation note: the code and evidence for this article are in the corrected companion package. That workflow deliberately stops at notification candidates; I have not treated untested delivery as finished.

Retrieval and change detection are different jobs

The Actor reads Telegram’s public t.me/s/ preview and returns recent messages in newest-first order. Each item includes fields such as:

{
  "channel": "telegram",
  "id": 454,
  "url": "https://t.me/telegram/454",
  "date": "2026-07-19T17:58:20+00:00",
  "text": "For all the details on these new features...",
  "views": 1180000,
  "scraped_at": "2026-08-05T14:13:17.444080+00:00"
}

That is enough to answer:

What is visible now?

It is not enough to answer:

What appeared since the previous successful check?

The second question requires historical information. That history can live inside an Actor, in a database, in a caller-supplied cursor, or in the workflow that calls the Actor. For this implementation, I kept the Actor stateless and made the downstream n8n workflow own the comparison state.

The boundary looks like this:

Schedule
   │
   ▼
Run Apify Actor ──► current message window
                         │
                         ▼
              validate and partition records
                         │
                         ▼
              compare with durable seen state
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
      notification candidates   status and warnings
              │                     │
              └──────────┬──────────┘
                         ▼
                  persist new state

The experiment that exposed the missing layer

I first called the Actor from an AI client through the Apify MCP server. I retained four one-call conditions:

Condition	What the caller knew before the run	Could it determine new IDs?
Baseline	No previous result	Not asked; the result became the baseline
Same conversation	Previous IDs were still in context	Yes
Fresh session	No reachable previous result	No; newness was undetermined
Fresh session with prior IDs	A small state file plus comparison rules	Yes

All four Actor runs succeeded and returned the same five IDs, 454 through 450. In the fresh session with no baseline, retrieval still worked, but comparison did not.

That result matters because “no new records” and “I cannot determine whether records are new” are not the same answer. A reliable monitor must preserve that distinction.

The runs also exposed a tempting identity bug: every message’s views value changed between two observations, while the IDs stayed stable. Comparing whole records would have classified all five messages as different. Comparing the stable identity classified them correctly as the same messages.

Choose identity before choosing storage

Telegram’s Bot API defines message_id as unique inside a chat. That means id alone is not a reusable global key. The monitor uses this partitioned identity instead:

(normalized channel, message ID)

For example:

function normalizeChannel(value) {
  return String(value ?? '')
    .trim()
    .replace(/^@/, '')
    .toLowerCase();
}

function messageKey(channel, id) {
  const normalizedChannel = normalizeChannel(channel);
  if (!normalizedChannel) {
    throw new Error('Channel is required.');
  }

  if (!Number.isSafeInteger(id) || id <= 0) {
    throw new Error('Message ID must be a positive safe integer.');
  }

  return JSON.stringify([normalizedChannel, String(id)]);
}

views and scraped_at are deliberately excluded. They can change without creating a new message. Text can also be edited, so an ID-only state detects new messages but does not detect edits; edit detection is a separate contract.

This is the first design rule:

Use immutable source identity for new-item detection. Do not let mutable attributes redefine the record.

Store a baseline, not a vague memory

A minimal prior-state file for one channel can be as small as:

{
  "schemaVersion": 1,
  "channel": "telegram",
  "identityField": "id",
  "sourceRunId": "example-prior-run-id",
  "seenMessageIds": [454, 453, 452, 451, 450]
}

The n8n workflow uses the same contract in a more compact form. Its global workflow state is partitioned by normalized channel, and positive integer IDs are stored as merged ranges:

{
  "schemaVersion": 1,
  "channels": {
    "telegram": {
      "initializedAt": "<timestamp from the first successful run>",
      "baselineFloorId": 450,
      "seenRanges": [[450, 454]],
      "highestObservedId": 454
    }
  }
}

Range compression is an implementation optimization, not part of the general monitoring rule. Set comparison requires stable identifiers; range compression additionally assumes suitable integer IDs.

The workflow reads this state with n8n’s $getWorkflowStaticData('global'). n8n documents three important constraints: static data is intended to be small, it is saved after successful triggered production executions, and it can be unreliable under high-frequency execution. That makes it acceptable for this small serialized demonstration, not a universal production database.

For growing state, overlapping executions, or operational querying, move the same identity and comparison contract to a Data Table or external database.

Make the first run a policy decision

On the first successful execution, every returned ID is unseen. Calling all of them “new” may be mathematically consistent, but it is usually terrible monitoring behavior: the workflow sends a burst of alerts for posts that existed before monitoring started.

This implementation defaults to baseline mode:

Fetch the first non-empty window.
Validate it.
Store the IDs.
Send no notification candidates.
Begin new-item detection on the next successful run.

An explicit alert mode remains available for workflows that really do want the first window delivered.

An empty result does not initialize the baseline. Otherwise a transient empty response could create an empty history, and the next normal result could replay the entire window as new.

Compare, classify, then persist

The core comparison is set difference:

new IDs = current IDs − previously seen IDs

But the order around that expression matters:

Validate the response shape and channel partition.
Reject unusable IDs.
Deduplicate the current window by the partitioned identity.
Compare against previously seen identities.
Apply the first-run and historical-backfill policies.
Generate notification candidates.
Persist every valid observed ID, including records filtered out by keywords.

That final choice gives keyword filters at-most-once behavior. Changing a keyword later does not replay posts the workflow already processed.

State corruption also fails closed. If a non-empty state object has no supported schema or contains malformed channel state, the workflow stops instead of silently treating history as empty. Resetting broken state would turn old records into a fresh alert storm.

The complete comparator and the n8n Code-node implementation are in the public companion repository. The comparator is dependency-free and accepts either a bare dataset array or an MCP-style { "items": [...] } envelope.

Treat a full polling window as a warning

Suppose the workflow requests five messages and receives five. It does not know whether exactly five were available or whether older unseen messages fell outside the returned window.

The workflow therefore sets windowSaturated using the raw Actor response count:

const windowSaturated = rows.length >= Number(monitor.limit);

The check happens before deduplication. Duplicate or invalid rows should not hide the fact that the raw window reached its cap.

Saturation means:

The configured window may be too small for the polling interval.

It does not prove that a message was missed. It tells the operator to consider a larger limit, a shorter interval, or a proper catch-up strategy.

The same reasoning applies in the other direction: an ID that was previously seen but is absent from a capped current window is not automatically deleted. It may simply have fallen beyond the window.

MCP proved the information boundary; n8n owns the recurring state

The two caller paths in this project are intentionally separate:

The experiment used an AI client and the Apify MCP server to test what could be determined with and without prior state.
The recurring implementation uses n8n and Apify’s synchronous REST endpoint to fetch dataset items, compare them with n8n workflow state, and emit candidates.

They call the same Actor, but they are not one combined MCP-to-n8n pipeline.

In n8n, the HTTP Request node calls:

POST https://api.apify.com/v2/acts/{ACTOR_ID}/run-sync-get-dataset-items

The Apify API documents this endpoint as running an Actor synchronously and returning its dataset items. Store the Apify API token in an n8n Bearer Auth credential; do not paste it into the workflow JSON.

What I verified

The corrected companion package includes:

a dependency-free comparator with 23 deterministic tests;
an importable n8n workflow whose embedded state engine has 11 deterministic tests;
a fail-closed state schema;
first-run baseline suppression;
per-channel state partitions;
duplicate prevention across triggered runs; and
saturation reporting based on the raw response count.

I also retained two successful triggered n8n executions:

Execution	Result
First triggered run	Created independent baselines for two channels; zero notification candidates
Second triggered run	Reused the persisted state; all ten returned IDs were already seen

The second execution reading the first execution’s state is the important result. It demonstrates persistence across triggered production runs rather than only inside one editor session.

What I did not verify

The evidence has limits:

No genuinely new live Telegram ID appeared during the retained runs. The positive new-ID path is covered by deterministic constructed tests.
The corrected public workflow stops at notification candidates; Telegram delivery is intentionally disabled and untested.
Every observed result window reached the configured limit of five, so the experiment does not establish catch-up completeness.
n8n workflow static data was tested only with small state and serialized executions.
The MCP experiment and n8n workflow ran at different times and are not a one-variable performance benchmark.

Those boundaries do not weaken the state contract. They define exactly what the implementation proves—and what the next production test must cover.

The checklist I now use for every scheduled Actor

Before turning any recurring Actor call into a monitor, I answer these questions:

What is the stable identity? Partition it by source, tenant, channel, or account where necessary.
Which fields are mutable? Keep them out of identity unless change detection is explicitly the goal.
Where does the baseline live? Give one layer clear ownership.
What happens on the first non-empty run? Baseline or alert—never accidental behavior.
What happens when state is missing or malformed? Fail closed instead of replaying history.
Can the polling window saturate? Surface that condition before deduplication.
What does absence mean? In a capped window, it does not prove deletion.
Can executions overlap? If yes, use storage with explicit concurrency guarantees.

A scheduled scraper repeatedly tells you what exists. A monitor tells you what changed without inventing certainty, replaying old records, or hiding gaps.

The difference is not another API call. It is a state contract.

Resources

AI assistance disclosure: I used AI tools during drafting, editing, and QA. I reviewed the final article and supporting evidence and take responsibility for its claims and conclusions.

Building Zero-Cost Multi-Agent AI Orchestrators & Local Assistants: My Journey with SwarmForge and O.D.I.N.

Thu, 17 Sep 2026 12:25:00 +0000

Building Zero-Cost Multi-Agent AI Orchestrators & Local Assistants: My Journey with SwarmForge and O.D.I.N.

By Kxrn

As a software developer and music producer, my daily workflow is a chaotic symphony of IDEs, digital audio workstations (DAWs), and an endless stream of background processes. I’ve always been obsessed with automation, but recently, I wanted to push the boundaries. I didn't just want basic scripts; I wanted assistants—systems capable of reasoning, orchestrating complex tasks, and managing my digital life without burning a hole in my wallet or melting my PC.

This is the story of how I built SwarmForge, a zero-cost multi-agent AI orchestrator, and O.D.I.N. (along with its counterpart, SHIVA), a highly efficient local assistant powered by a blend of Python and C++ Win32 daemons. If you want to dive into the code behind these tools, you can find my work on my GitHub profile.

Bridging the Gap: Python Wrappers & C++ Win32 Daemons

When building local assistants like O.D.I.N. and SHIVA, you quickly realize that Python is fantastic for AI logic, natural language processing, and API integrations. However, when it comes to raw system-level automation, keylogging, window management, or low-latency background processing on Windows, Python can feel like trying to run a marathon in flip-flops.

To solve this, I adopted a hybrid architecture: Python handles the brains, while C++ Win32 background daemons act as the muscle.

I wrote lightweight C++ executables that run silently in the background, interacting directly with the Win32 API. These daemons handle the heavy lifting—like granular process control, audio routing for my music production sessions, and system monitoring. Python then acts as a wrapper, communicating with these daemons via Inter-Process Communication (IPC) mechanisms like named pipes.

Here is a conceptual look at how O.D.I.N.'s Python brain sends commands to a C++ Win32 daemon:

import win32file
import win32pipe

def send_command_to_daemon(command: str):
    # Connect to the C++ Win32 Named Pipe
    pipe_name = r'\\.\pipe\ODIN_Daemon_Pipe'
    try:
        handle = win32file.CreateFile(
            pipe_name,
            win32file.GENERIC_READ | win32file.GENERIC_WRITE,
            0,
            None,
            win32file.OPEN_EXISTING,
            0,
            None
        )
        win32file.WriteFile(handle, command.encode('utf-8'))
        print(f"Command '{command}' dispatched to O.D.I.N. C++ daemon.")
    except Exception as e:
        print(f"Daemon communication failed: {e}")

This hybrid approach ensures that the system footprint remains minuscule, which is critical for reasons I'll explain later.

Forging the Swarm: The Architecture of SwarmForge

While O.D.I.N. acts as my personal system-level assistant, I also needed something to help me write and manage code. Enter SwarmForge, my zero-cost multi-agent AI coding orchestrator.

The goal of SwarmForge was to create a hierarchical team of AI agents—a manager, a researcher, a coder, and a reviewer—that could tackle complex coding tasks autonomously. And it had to cost zero dollars to run, leveraging free-tier APIs and local models.

How SwarmForge Works

The Orchestrator: The main node receives my natural language prompt and breaks it down into sub-tasks.
Dynamic Provisioning: SwarmForge spins up specialized agents based on the task requirements.
Shared Memory Workspace: Instead of passing massive context windows back and forth (which is expensive and slow), agents read and write to a centralized markdown-based memory pool and a virtual file system.

By keeping the context lean and strictly defining agent roles, SwarmForge achieves high-quality code generation without the API costs usually associated with large-scale multi-agent systems.

The Reality Check: Overcoming Hardware Constraints

It’s easy to design elegant architectures on paper. It’s entirely different when you have to run them on a modest rig. My workstation is powered by an Intel Core i7-4790, 16GB of RAM, and a GTX 1050 OC. By today's AI standards, this is a potato.

Running LLMs, Python orchestrators, C++ background daemons, and an instance of a DAW simultaneously on this hardware is an absolute battle for resources. Here is how I survived:

1. Ruthless Memory Management

With only 16GB of RAM, swapping to disk is a death sentence for performance. SwarmForge uses a "lazy-loading" approach for its agents. They are instantiated only when needed and immediately destroyed after their task is logged to the Shared Context Pool.

2. Offloading and Quantization

For local inference, the GTX 1050 OC (with a mere 2GB of VRAM) means standard models are out of the question. I rely heavily on quantized models (GGUF format, Q3 or Q4) loaded primarily into system RAM, using the GPU only to accelerate a few layers. It’s not blindingly fast, but it works.

3. C++ to the Rescue

This is where the C++ Win32 daemons in O.D.I.N. and SHIVA truly paid off. A Python script polling the system every second consumes noticeable CPU cycles. A C++ daemon utilizing Win32 event hooks (SetWindowsHookEx) consumes effectively zero CPU overhead until an event triggers it. This saved precious compute bandwidth for the AI models.

Final Thoughts

Building zero-cost multi-agent orchestrators and highly integrated local assistants isn't just about throwing LLMs at a problem. It's about engineering solutions that respect the constraints of your hardware. By marrying the rapid prototyping of Python with the low-level efficiency of C++ Win32 APIs, I was able to turn my aging i7-4790 into a powerhouse of automated productivity.

Whether I'm producing my next track or engineering a new feature, SwarmForge and O.D.I.N. are always running quietly in the background, ready to assist.

If you’re interested in collaborating, want to see my music, or just want to chat about AI and development, check out my developer portfolio or explore the source code of my projects over on GitHub.

The Trigger Swap That Broke Every Downstream Reference

Tue, 15 Sep 2026 13:15:42 +0000

I built this workflow — a lead intake automation for a made-up client, Ferrer Window Co. — with a Form Trigger first, even though I knew from the start it needed to end up on a Webhook. That wasn't the plan drifting. It was deliberate: I'd used webhooks before and Form Trigger less, so building with Form Trigger first let me see real data coming through without also holding webhook payload structure in my head at the same time. Get the logic right, then swap the trigger once everything else was solid.

And the logic did get solid. By the time I was ready to swap, I had a full chain working: an IF node filtering out junk leads (both phone and email empty), a Set node defaulting empty message fields to "No message provided," and Sheets and Slack both branching off that same cleaned data independently. Tested both edge cases — junk lead correctly stopped, empty message correctly defaulted. Everything passed.

Then I deleted the Form Trigger, added a Webhook node, and sent a test payload through Postman.

It broke immediately.

Not the logic — the logic was fine. What broke was every single reference to the data. With Form Trigger, the payload had come through flat:

{
  "Name": "Tarek",
  "Phone": "02-011-41104-582",
  "Email": "*Emails are not allowed*",
  "Service address": "Primary school st",
  "Message": "I want to request an order",
  "submittedAt": "2026-08-24T03:24:50.089-04:00",
  "formMode": "test"
}

With Webhook, everything I actually wanted was nested one level down, sitting alongside a pile of raw HTTP metadata I didn't need:

{
  "headers": {...},
  "body": {
    "Name": "Tarek",
    "Phone": "02-011-41104-582",
    ...
  },
  "webhookUrl": "...",
  "executionMode": "test"
}

Every reference I'd written — the IF node's condition, the Set node's field mappings — pointed at $json.Name, $json.Phone, and so on. None of it was wrong, exactly. It was just pointed at a shape of data that no longer existed. The whole workflow's reasoning was intact and now unreachable.

So I went back through it node by node — the IF node's conditions, the Set node's mappings — and repointed every one from $json.X to $json.body.X. Nothing about what the workflow decided changed. Only where it looked for the thing it was deciding about.

Once that was done, I didn't just assume it worked because the references compiled. I re-ran both edge cases through the webhook path — both phone and email empty, and an empty message field — to confirm the filter still stopped junk leads and the default still kicked in, now that the data was arriving through a different shape entirely.

The part I'd flag for anyone doing this same swap later: it's not a dramatic failure. Nothing throws a loud error that points you at the fix. The workflow just quietly stops seeing the data it expects, because the trigger node changed the shape of what "the data" even means. If you built your logic against one trigger's payload structure, swapping the trigger isn't a drop-in replacement — it's a second pass through everything downstream, checking what each node thinks it's looking at.

Why I Built Codevise — and What I Learned While Turning an Idea Into a Real Product

Sun, 13 Sep 2026 17:08:30 +0000

Most projects start with an idea.

Some remain ideas.

Some become a GitHub repository that gets abandoned after a few weeks.

And a very small number turn into something you genuinely want to keep building.

Codevise started as an idea.

But somewhere along the way, it became more than just another project in my portfolio. It became an experiment in understanding what it actually takes to build, improve, break, rebuild, and eventually ship something real.

This is the story of Codevise.

The Problem

As developers, we spend a huge amount of time learning.

We jump between documentation, tutorials, videos, GitHub repositories, Stack Overflow, AI tools, blog posts, and countless other resources.

The information is everywhere.

But having access to information isn't necessarily the same thing as knowing what to do with it.

You can learn a programming language without knowing how to build a project.

You can understand an algorithm without knowing when to use it.

You can watch ten tutorials about a technology and still feel completely lost when you open an empty code editor.

That gap between learning something and actually being able to use it is what interested me.

I didn't want to build something that simply gave developers more information.

I wanted to explore the idea of building something that could make the learning and development process more structured, practical, and useful.

That idea eventually became Codevise.

What Is Codevise?

At its core, Codevise is my attempt to build a better environment for developers to learn, experiment, and improve.

The goal isn't simply to provide another place where someone can read about programming.

The bigger idea is to help turn:

“I want to learn this.”

into:

“I know what to build, how to approach it, and why I'm doing it.”

That difference is important.

Learning becomes much more meaningful when you can immediately apply it.

Instead of treating programming as a collection of isolated concepts, Codevise is built around the idea of connecting knowledge → practice → projects → improvement.

Why Build It Myself?

There are already countless developer platforms.

So the obvious question is:

Why build another one?

The answer is simple.

Because building something yourself teaches you things that consuming someone else's product never can.

When you're building a product, there is nowhere to hide.

You have to think about the user.

You have to think about the interface.

You have to think about the architecture.

You have to make decisions when there isn't a perfect answer.

And eventually, you have to ship.

That process was one of the biggest reasons I wanted to build Codevise.

I didn't want Codevise to be just another project that looked good in a portfolio.

I wanted it to be a project that forced me to become a better developer.

Starting Small

One of the biggest lessons I've learned from building projects is that the first version doesn't need to be perfect.

In fact, trying to make version one perfect is one of the easiest ways to never release version one.

So Codevise started with a simple objective:

Build the core experience first.

The goal was to get something functional before worrying about making everything sophisticated.

That meant making decisions about what actually mattered.

What should the first user see?

What is the most important interaction?

Which features are essential?

Which features can wait?

Those questions sound simple.

They're not.

When you're building your own product, every feature sounds important.

The difficult part isn't coming up with ideas.

The difficult part is saying:

“Not yet.”

The Engineering Behind the Idea

Building a product also changes the way you think about technology.

When you're solving a coding problem, you usually have a clearly defined input, output, and set of constraints.

Product development is different.

The problem itself can change while you're solving it.

A technical decision that looks perfect today might become a limitation later.

A feature that seemed essential might turn out to be unnecessary.

A simple implementation can sometimes be better than an over-engineered one.

Codevise has therefore been as much an exercise in engineering judgment as it has been in writing code.

The important question isn't always:

“Can I build this?”

It's:

“Should I build this, and what is the simplest way to build it well?”

That distinction is something I increasingly appreciate.

The Parts Nobody Sees

One thing that doesn't show up in a final product is how many times things don't work.

A feature can look straightforward on paper and become surprisingly complicated during implementation.

You fix one problem and create another.

You change one part of the application and something completely unrelated breaks.

You spend an hour debugging something that turns out to be a tiny mistake.

And sometimes you realize that the approach you spent hours implementing wasn't the right approach at all.

That's normal.

It's also where a lot of the learning happens.

Building Codevise reminded me that development isn't about writing perfect code from the beginning.

It's about being able to identify problems, understand them, and keep improving the system.

Building Is Different From Learning

This has probably been one of my biggest takeaways.

You can study software engineering for months.

You can solve hundreds of coding problems.

You can learn multiple programming languages.

But when you start building an actual product, you encounter an entirely different category of problems.

Suddenly, you have to think about things like:

User experience
Maintainability
Architecture
Performance
Error handling
Security
Deployment
Scalability
Product decisions
Trade-offs

And there isn't always a textbook answer.

Sometimes you have to make a decision with incomplete information.

Then observe what happens.

Then change it.

That's engineering.

Codevise Is Also an Experiment

I don't see Codevise as a finished product.

I see it as an evolving experiment.

The initial idea is rarely the final idea.

As you build, your understanding changes.

You discover what works.

You discover what doesn't.

You notice problems you didn't anticipate.

You find opportunities you didn't initially consider.

And the product evolves with that understanding.

That's why I'm comfortable saying that Codevise is still being built.

The goal isn't to pretend that everything is finished.

The goal is to keep making it better.

What I Want Codevise to Become

The long-term vision is bigger than simply creating another developer platform.

I want Codevise to become a place where developers can move through the entire journey:

Learn → Practice → Build → Improve.

Learning shouldn't end when the tutorial ends.

Solving a problem shouldn't end when the code passes the test cases.

Building a project shouldn't end when it works on your laptop.

There is always another level.

A better implementation.

A cleaner architecture.

A stronger understanding.

A more useful product.

That continuous improvement mindset is at the heart of what I want Codevise to represent.

What Building Codevise Has Taught Me

If I had to summarize the biggest lessons so far, they would be these.

1. Start before you feel ready

You will never know everything before starting.

You learn a huge amount once you actually begin building.

2. Simple beats complicated

It's tempting to build the most impressive architecture possible.

But a simple system that works is infinitely more valuable than a complicated system that doesn't.

3. Shipping teaches differently

A project sitting on your machine can teach you a lot.

A project that other people can actually use teaches you even more.

4. Failure is part of development

Bugs, rewrites, bad decisions, and failed approaches aren't evidence that you're bad at development.

They're part of development.

5. The product is never really finished

There is always something that can be improved.

The real skill is knowing what deserves your attention next.

More Than a Project

When I look at Codevise, I don't just see lines of code.

I see the decisions behind them.

The experiments.

The debugging sessions.

The features that changed.

The things that didn't work.

The ideas that became better after implementation.

And most importantly, the skills I gained while building them.

That's what makes personal projects valuable.

A project doesn't have to become the next billion-dollar company to be worthwhile.

Sometimes its biggest value is what it teaches the person who built it.

Codevise has already done that for me.

What's Next?

There is still a lot to build.