DEV Community: karan kartikeya

Pheromone: Coding Agents works together like Ants using Falkor DB

karan kartikeya — Sun, 18 Oct 2026 10:39:12 +0000

Introduction:

A quick thanks to @WeMakeDevs and FalkorDB for hosting this awesome hackathon Graph Hacks.

1. The problem🤷‍♂️

Upgrading a Python codebase from Pydantic v1 to v2 is a classic long-tail job. The official codemod, bump-pydantic, rewrites the easy parts and leaves # TODO[pydantic] markers on the rest: validators that read values, .dict() and .json() calls it can't see, removed config keys, custom types built on __get_validators__, and behaviour that quietly changed (unions, coercion, JSON output). That tail is exactly the kind of work you'd like to hand to several agents at once.

Problems that occur while several LLM agents work:

They don't share memory
They attempt the same method and try to fix the already fixed library
Keep running into same failures

2. Stigmergy (A fancy term)😎

Ants don't hold meetings. An ant that finds food lays a pheromone trail on the way back; other ants are more likely to follow strong trails; trails nobody reinforces evaporate. Coordination emerges from the environment, not from messages. Biologists call this stigmergy.

Pheromone applies that to coding agents. The environment is a FalkorDB graph.

A failing test points to a Failure; each Failure has candidate fixes (Hypotheses);
The edge between them carries a pheromone value. Agents pick hypotheses by a weighted roulette over pheromone, claim one with a single atomic query, try it, and report.
Only test results change pheromone: a fix that passes reinforces its trail, a fix that fails decays it, and everything evaporates a little every ten seconds.
The idea got motivated from LLM agents in MIT's SwarmWorld work; here it runs on real code with tests as the only judge.

3. Why a graph, not a key-value blackboard📊

I have worked on Agentic memory for sometime and also have had the experience of building an agentic open source memory named Engram-Causal, which mainly answers why did a particular function call passed/failed instead of what the agent did.

A shared dictionary of "who is doing what" would cover claims. The graph earns its place in three other ways.

Blast radius. Every repo file is a node with IMPORTS edges to the files it imports. Before a patch merges, the merge gate collects every test that could notice the change with one variable-length match, (f:File {path:$path})<-[:IMPORTS*0..3]-(dep:File)<-[:DEFINED_IN]-(t:Test), and requires them to stay green. That's a multi-hop question a flat store can't answer cheaply.

The trail behind a fix. Every attempt is a node linked to the agent that made it, the hypothesis it tested and the tests it fixed or broke. "Why is this test green?" is one path query from Test through Failure, Hypothesis and Attempt to Agent, and the dashboard renders that path with the diff.

Memory that outlives a run. When the same kind of fix wins in several places, it becomes a Recipe in a separate recipes graph. A run on a different repo seeds its hypotheses from Recipes whose signature matches. Signatures (dict-call, validator-values, json-encoders) never contain file paths, which is what lets them transfer.

Graph algorithms help the agents too: PageRank over the import graph raises the prior on central modules, and weakly connected components group failures into independent clusters.

4. Two FalkorDB lessons (and two lessons about tests)👨‍💻

There are no multi-query transactions, so every coordination step is one query. FalkorDB serializes writes to a graph and each query is atomic, but you can't wrap a read and a write from Python in a transaction. A claim is therefore a compare-and-set in a single statement: match the hypothesis where it's open or its lease has expired, set the new owner, return the id. An empty result means another agent won. Twenty concurrent claims on the same hypothesis produce exactly one winner, and that's a test in the repo.

SET runs on every matched row, even if a LIMIT comes later. A "pick the top candidate and claim it" query with SET ... LIMIT 1 claims every candidate. So the frontier read and the claim are separate queries, and the claim always targets one id.

We also hit a server crash: a read returning node properties together with collect() on a hypothesis that had just been claimed panicked inside reply_compact. Splitting it into plain-row queries fixed it.

Two lessons came from the tests, not the database:

Tests decide, so tests can be fooled. An agent once made a frozen-model test pass by overriding __eq__ and __setattr__ instead of setting frozen=True. Pydantic's warning about the leftover allow_mutation key was only a UserWarning, so the suite didn't catch it. Treating UserWarning as an error, and telling agents not to override dunder methods, fixed it.
Real test suites hide the real error. On robusta-dev/krr the swarm stalled with 13 red tests. The CLI under test caught the actual exception (a deprecated .dict() call in the runner), logged it and exited with code 1, so the test only reported an exit code. And krr's tests depend on run order: a subset of tests can fail where the full suite passes, so correct fixes were rejected as regressions. Reading the logged traceback as the failure's cause, and judging regressions against the same test selection run before the patch, took krr from 42 to all 55 tests green. Along the way the swarm also fixed a deprecated result.json(indent=2) that the human migration PR had left in place.

5. The scoreboard🧮

I ran the same six agents four ways, with the same model (gpt-6-luna), budget, prompts, hypothesis templates and merge gate. Fifty runs, shuffled, on frozen code, every one ending with all tests green:

Baseline: independent agents, no shared graph.
Coordinated: shared graph, claims, leases and attempt history, with pheromone switched off.
Swarm: Coordinated plus pheromone-weighted selection.
Swarm + Recipes: Swarm plus fixes learned on earlier runs (krr only).

	Tokens	Time to green	Collisions
gym, Baseline (10 runs)	150k	166 s	124
gym, Coordinated (10)	47k	72 s	7
gym, Swarm (10)	48k	73 s	8
krr, Baseline (5)	178k	243 s	88
krr, Coordinated (5)	121k	207 s	11
krr, Swarm (5)	119k	205 s	13
krr, Swarm + Recipes (5)	101k	253 s	5

Shared state is what works. Against independent agents, the graph-coordinated modes used about two thirds fewer tokens on the gym and a third fewer on krr, and collided roughly ten times less often. On the gym they were also more than twice as fast. krr's failures form a chain where each fix reveals the next layer, so the time gain there is smaller.

Where it didn't win: pheromone. Turning pheromone-weighted selection off changed nothing measurable on either repo. The gains come from shared claims, leases and attempt history. That's partly because the model fixes most of these failures on the first try, which leaves pheromone little to choose between; harder targets, where most attempts fail, are where reinforcement would have to prove itself. Recipes are inconclusive too: they produced 80% of the merged krr fixes and lowered median tokens by 15%, but the ranges overlap and one run was slow.

The coordination itself held up under load. Thirty agents hammering the claim and report queries for a minute, with short leases and agents that stall on purpose, produced no double claims, no reports accepted after another agent took over, and pheromone values identical to an exact replay. FalkorDB's default queue cap pushed back at that load, which the agents absorbed with backoff.

6. What's next⏭️

Find out if Recipes compound: Recipes produced most of the fixes on krr but didn't measurably cut cost over five runs, partly because the hand-written templates already covered what krr needed. The interesting experiment is a run of ten or more real repositories in a row. If the tenth migration is clearly cheaper than the first, the shared memory is worth something no single run can show.

Isolate the graph itself Our baseline compares coordinated agents with independent ones. It doesn't tell you how much of the gain needs a graph rather than any shared store. Rebuilding the claims, leases and history on a key-value store, with the same scheduler, would answer that directly. My bet is that the graph's value lies in the questions you can ask afterwards (blast radius, provenance, why a fix won) more than in raw speed, and I'd like to measure it.

Leave the gym: The gym was written for this project and krr is one repository. Next is a handful of real open-source repos with pending Pydantic v2 migrations, opening the swarm's diffs as pull requests and counting how many maintainers merge. Other long-tail upgrades (SQLAlchemy 2.0, Django, NumPy 2) fit the same loop.

ERC-8004, Explained for People Who Don't Want to Read the EIP

karan kartikeya — Mon, 13 Jul 2026 09:14:06 +0000

Two agents try to transact. One was built on LangChain, the other on a completely different stack nobody's heard of. Neither has any shared way to prove who it is to the other, let alone whether it's done this before and done it well.

They can still send a payment. Wallets don't care what framework built you. But payment was never the hard part — knowing who's on the other end of it is.

This happens constantly right now, and almost nobody building agent products is talking about it, because it's not a flashy problem. It's a plumbing problem. Every agent framework today is excellent at orchestration inside its own walls and useless at identity outside them. An agent built in one system is functionally invisible to an agent built in another. No shared name, no shared history, no shared anything.

That fragmentation is the actual ceiling on agent-to-agent commerce. Not compute, not payments rails, not even trust in the abstract sense — just the boring fact that agents can't legibly recognize each other across systems.

ERC-8004 is the attempt to fix that. Not a product, not a company's internal solution — a shared on-chain standard so any agent, from any framework, can be identified and read the same way by anyone else, anywhere.

It's built around two registries, and they solve two genuinely different problems.

The Identity Registry gives an agent a durable, portable identity that lives on-chain instead of inside whatever platform spun it up. Right now, an agent's "identity" is usually just an account inside someone else's system — delete the account, and the agent's entire existence goes with it. An on-chain identity survives that. It's not owned by the marketplace, the framework, or the hosting provider. It's the agent's own.

The Reputation Registry does the equivalent for history. Instead of an agent's track record being trapped inside one marketplace's private database — invisible to everyone else, worthless the moment the agent shows up somewhere new — it gives history a standard place to live where any counterparty can read it. Same structure, whoever's asking.

Here's the part that's easy to undersell: this only works if it's a standard and not a product. If every marketplace built its own version of an identity or reputation registry, agents would be back to square one — legible in one place, invisible everywhere else. The value isn't the registry itself. It's that everyone reads it the same way. That's a coordination problem, not an engineering one, and coordination problems are usually the hardest ones to actually ship.

Think about what DNS did for the internet. Nobody wakes up excited about DNS. It's invisible until the moment it isn't there, and then nothing resolves. That's the category ERC-8004 is aiming for — boring, load-bearing infrastructure that everything downstream just assumes exists. Once it does, entire categories of products get built on the assumption, the same way nobody building a website today thinks twice about domain resolution.

But a standard existing doesn't automatically make the data inside it useful. This is the part most explanations skip. An Identity Registry entry tells you an agent exists and has a durable identifier. A Reputation Registry entry gives that agent a place where its history could live. Neither one, by itself, tells a counterparty whether that agent is actually trustworthy.

Raw entries in a registry are closer to a filing cabinet than a credit score. The registry says the folder exists. It doesn't read the folder for you, weigh what's in it, or tell you whether the pattern of behavior inside it should worry you or reassure you. Someone still has to turn on-chain activity into an actual usable signal — something an insurer, a marketplace, or a service provider can query in real time and get a real answer from, not just a pointer to raw data they'd have to interpret themselves.

That gap — the standard exists, the interpretation layer doesn't yet — is exactly where the next piece gets built. Not a competing standard. A layer that sits on top of ERC-8004 and does the work of turning registry entries into something you can actually act on.

We've deployed both the Identity Registry and Reputation Registry live on Base mainnet at SwarmPay, and we're building the indexing layer on top that turns what's in them into an actual queryable reputation score. More on how that scoring works soon.

If you want early access as this rolls out, sign up for the SwarmPay waitlist.

Build a paid membership site using SAWO and Stripe

karan kartikeya — Thu, 25 Nov 2021 08:17:21 +0000

Build a paid membership site with Stripe and Sawo

Stripe: Online payment processing for internet businesses. Stripe is a suite of payment APIs that powers commerce for online businesses of all sizes.

Requirements

Node.js 15.5+ or later
MacOS, Windows (including WSL), and Linux are supported
npm (comes bundled with node.js) or yarn

Steps

1. Generate SAWO API key

Navigate to SAWO Dashboard or create a new account here and log in.
In the SAWO dashboard, click on the create project button at the bottom left to create a new project.
Choose web and then code since we're working with react framework and will be writing the custom code ourselves.

Click continue. You'll see a similar prompt like the one below.

Name your project with a relevant name. 2.1 For development in a local machine, the hostname should be set to 'localhost'.

If using "localhost" as hostname is not working for you, try "127.0.0.1"

2.2 For production, the hostname should be set to your domain.

If you are adding your domain do not add 'https://', ''http://', 'www' or even trailing backslash. Example: https://dev.sawolabs.com/ should be kept as dev.sawolabs.com

On clicking the create button, we can successfully see the API key created prompt and SAWO keys csv file downloaded.

2. Generate Stripe API key and create a product with price

Navigate to Stripe Dashboard or create a new account here and log in.
In the Stripe dashboard, click on the developers option.
In the developers section head to API keys, and there you can find the secret key and publishable key.
Move to the products option to create your products with prices.
You will be able to see your price id in front of the price info after creating the product.

3. Install the dependencies

Enter the following command in the terminal to create a Next.js app.

npm i stripe, express

4. Make endpoints in index.js file and serve your HTML files

Now, create an instance of express and path

  const express = require("express");
  const app = express();
  const path = require("path");

Serve the html files

  app.use(express.static(path.join(__dirname, "public")));
  app.get("/", (req, res) => {
  res.sendFile(__dirname + "/index.html");
  });
  app.get("/login", (req, res) => {
  res.sendFile(__dirname + "/public/login.html");
  });
  app.get("/success", (req, res) => {
  res.sendFile(__dirname + "/public/success.html");
  });
  app.listen("3000", console.log("Listening on port 3000."));

Next, let's create an instance of stripe

  const stripe = require('stripe')('YOUR_STRIPE_SECRET_KEY');

Import the price id generated above

  const priceId = 'YOUR_PRICE_ID';

Create a Checkout Session for Stripe

  const session = await stripe.checkout.sessions.create({
    billing_address_collection: 'auto',
    line_items: [
      {
        price: prices.data[0].id,
        // For metered billing, do not pass quantity
        quantity: 1,

      },
    ],
    mode: 'subscription',
    success_url: `${YOUR_DOMAIN}/success.html?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${YOUR_DOMAIN}/cancel.html`,
  });

  res.redirect(303, session.url);
  });

Get the price from lookup key

  const prices = await stripe.prices.list({
    lookup_keys: [req.body.lookup_key],
    expand: ['data.product'],
  });

Define the line items:

  line_items: [
      {
        price: prices.data[0].id,
        // For metered billing, do not pass quantity
        quantity: 1,

      },
    ],

Define the success and cancel urls:

    success_url: `${YOUR_DOMAIN}/success.html?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${YOUR_DOMAIN}/cancel.html`,

Create a customer portal session:

  const returnUrl = YOUR_DOMAIN;

  const portalSession = await stripe.billingPortal.sessions.create({
    customer: checkoutSession.customer,
    return_url: returnUrl,
  });

Provision access:

  app.post(
  '/webhook',
  express.raw({ type: 'application/json' }),
  (request, response) => {
    const event = request.body;
    // Replace this endpoint secret with your endpoint's unique secret
    // If you are testing with the CLI, find the secret by running 'stripe listen'
    // If you are using an endpoint defined with the API or dashboard, look in your webhook settings
    // at https://dashboard.stripe.com/webhooks
    const endpointSecret = 'whsec_12345';
    // Only verify the event if you have an endpoint secret defined.
    // Otherwise use the basic event deserialized with JSON.parse
    if (endpointSecret) {
      // Get the signature sent by Stripe
      const signature = request.headers['stripe-signature'];
      try {
        event = stripe.webhooks.constructEvent(
          request.body,
          signature,
          endpointSecret
        );
      } catch (err) {
        console.log(`⚠️  Webhook signature verification failed.`, err.message);
        return response.sendStatus(400);
      }
    }
    let subscription;
    let status;
    // Handle the event
    switch (event.type) {
      case 'customer.subscription.trial_will_end':
        subscription = event.data.object;
        status = subscription.status;
        console.log(`Subscription status is ${status}.`);
        // Then define and call a method to handle the subscription trial ending.
        // handleSubscriptionTrialEnding(subscription);
        break;
      case 'customer.subscription.deleted':
        subscription = event.data.object;
        status = subscription.status;
        console.log(`Subscription status is ${status}.`);
        // Then define and call a method to handle the subscription deleted.
        // handleSubscriptionDeleted(subscriptionDeleted);
        break;
      case 'customer.subscription.created':
        subscription = event.data.object;
        status = subscription.status;
        console.log(`Subscription status is ${status}.`);
        // Then define and call a method to handle the subscription created.
        // handleSubscriptionCreated(subscription);
        break;
      case 'customer.subscription.updated':
        subscription = event.data.object;
        status = subscription.status;
        console.log(`Subscription status is ${status}.`);
        // Then define and call a method to handle the subscription update.
        // handleSubscriptionUpdated(subscription);
        break;
      default:
        // Unexpected event type
        console.log(`Unhandled event type ${event.type}.`);
    }
    // Return a 200 response to acknowledge receipt of the event
    response.send();
  }
  );

If you have followed the tutorial well, you'll see a checkout form similar to the one given below when you head to buying membership button on homepage.

Conclusion

Congratulations! You have made it till the end and have learnt how to implement authentication in SAWO and also integrated Stripe API for paid membership. In case you're facing difficulties, here's a working demo of the tutorial you just went over. Find the source code for the same here.

What's Next?

Now that you've learnt how to build a paid-membership site using Stripe and Sawo, feel free to look at the SAWO documentation and integrate some new features in this demo application by forking it in your repo.

How to contribute to a NodeJS project uploaded on the Github account of an organization or developer using Git?

karan kartikeya — Thu, 24 Dec 2020 11:31:20 +0000

STEPS

Installation of the dependencies and IDE
Forking the Project
Cloning it on your local system
Make changes
Committing changes to the Forked repository
Make a pull request

1. Installation of the dependencies

Dependencies that are to be installed for a NodeJs project are:

Install the above dependencies as per your operating system.

2. Forking the Project

This step is not necessary for those wishing to directly contribute and does not want to just pile up the repositories in their account.Those people can skip to the 3rd step directly.
Now suppose we have to contribute to the below repository, therefore we would need to fork this on our own repository first to edit it. Forking is just like making a copy of something. Therefore we click the Fork button available at the top right corner.

Then choose the account in which you want to fork it.

Well done!!! You have successfully forked the repository.

3. Cloning it on your local system

Now lets start cloning it to our local system.
Head to the forked repository in your account and click on option 'Code' which would result in a dropdown menu. Select the notepad like icon next to the given link and the given link would be copied.

Next, open your VS code and click the 'clone repository' option available next to the 'Open folder'.

After clicking it paste the link to the dialog box which appears and press the Enter key.

A pop-up window appears asking for the local storage of the repository. Choose the desired location and wait for the cloning process to finish.
Great job!!! You have successfully cloned the repository and it's showing in the sidebar.

4.Make Changes

Now we are good to make the changes in the project. So I would be showing you how to make this project a NodeJs project.
So follow these steps:

Click the Terminal option and choose New Terminal
Type npm init
After this fill in the asked details according to your preference or just keep pressing the Enter key.
Now you can see a package.json file created in the root directory.
After this you can install Express.js(NodeJs Framework) by typing npm install express. This would install the Express.js framework in your package file.

For users who get an error like:

 npm is not recognized as an internal command...

can get it solved from here.

For users who get an error like:

 git is not recognized as an internal command...

can get it solved from here.

After installing Express.Js, Make an index.js file in the root directory by clicking the new file option in the sidebar above package.json file.
In the index.js file paste the code given here.
Now again head to the terminal window and type node index.js. You will see a output like this

Example app listening at http://localhost:3000

Open up your browser and open the port 3000 and congrats you have successfully set up an express app. Move back to the terminal in the VS code and press ctrl+c to close the server.

5.Committing changes to the Forked repository

Now what's left is just committing your work to the Github repository of yours. So let's begin:

Open the terminal and type

   git add .

This command would add all the changes made to the Local
Repository.

Next command is

  git commit -m "Project Upload"

This command would commit your changes which are ready to be pushed to the main branch. You can change the message("Project Upload") according to your convenience.

In the end type

  git push -u origin main

This command would push all the changes to your Github account Repository. Refresh your Github Repository page and you would see the changes like this.

6. Making a pull request

Click on the pull requests option from above and click the New Pull Request option.

Click the Create Pull Request option and your works done.
Great Job!!! You have successfully made changes to the project and created a pull request. Now just relax and wait for your pull request to get merged by the organization.

So now you all know how to set up the environment for a NodeJs project and some of the git commands.

DEV Community: karan kartikeya

Pheromone: Coding Agents works together like Ants using Falkor DB

Introduction:

1. The problem🤷‍♂️

2. Stigmergy (A fancy term)😎

3. Why a graph, not a key-value blackboard📊

4. Two FalkorDB lessons (and two lessons about tests)👨‍💻

5. The scoreboard🧮

6. What's next⏭️

ERC-8004, Explained for People Who Don't Want to Read the EIP

Build a paid membership site using SAWO and Stripe

Build a paid membership site with Stripe and Sawo

Requirements

Steps

1. Generate SAWO API key

2. Generate Stripe API key and create a product with price

3. Install the dependencies

4. Make endpoints in index.js file and serve your HTML files

Conclusion

What's Next?

How to contribute to a NodeJS project uploaded on the Github account of an organization or developer using Git?

STEPS

1. Installation of the dependencies

2. Forking the Project

3. Cloning it on your local system

4.Make Changes

5.Committing changes to the Forked repository

6. Making a pull request

Contact me: