Problem:
Agent swarms fill forms, bookings, and signups until real people cannot get through. The flows that make revenue lock up: a calendar of fake appointments, a CRM of invented leads, a waitlist that is mostly scripts. Rate limits that were tuned for people look like downtime once non-human traffic is the majority of the pipe.
Classic CAPTCHA is a blunt instrument. It punishes the human you wanted and barely slows a determined agent. IP lists rot. User-agent strings are costumes. Meanwhile the rest of the internet is shifting toward agents as a normal client, which is the point of Most internet traffic is no longer human. Defense that treats every non-browser as an attack will also treat the assistant that a real customer asked to book a slot.
The product problem is classification with a cost function. False positives lose bookings. False negatives fill the queue. Most teams only see the wreckage after a spike, because their analytics still count sessions as if they were people. Agent traffic analytics is the measurement half of that story. This service is the gate on the forms that cannot go down.
Approach:
Carbonology tells humans from automated traffic so those critical flows stay usable when agent volume spikes, without punishing the people the form was built for. We start by naming the flows that matter — booking, signup, checkout, login, admin — and by looking at how they fail today. The first deliverable is often a picture of the abuse, not a widget.
Then we put verification where it pays for itself. That can be a challenge on submit, a quieter risk score, allow and deny rules for known agent classes, or a human step that only appears when the request looks automated. We do not sell a single vendor checkbox as a strategy. The implementation has to match the flow and the risk.
We also write down what should happen when an agent is welcome. Some traffic is a crawler you asked for. Some is a user's assistant trying to complete a task you will later want to support with a plugin. Defense and discovery are the same practice looked at from two sides. Contact us with the URL of the form that is already hurting.
Deliverables:
- A map of the flows worth protecting and the failure mode each one is already showing.
- A classification approach: what we will treat as human, unknown, welcome agent, and hostile automation.
- Implementation on the existing site or app — challenges, scoring, rate rules, or a combination — documented so you can change thresholds.
- Logging that later feeds analytics, so the gate is not a black box the next time volume moves.
- Copy and UX for the human path, so verification does not read like an accusation.
- A short runbook for the next spike: what to tighten, what not to panic-block.
Who it's for:
Sites whose bookings, signups, or admin tools are already taking automated abuse, and teams that can see a coming wave because their category is easy to script. Also useful before a launch that will be announced in places agents scrape first.
If the only symptom is “our analytics look weird,” start with agent traffic analytics. If a form is already unusable, start here.
Related:
Questions:
No, and it should not. Search crawlers and some agents are useful. The work is to keep hostile or accidental swarms off the forms that have to stay empty for people, without lying to yourself that the rest of the site has no automated traffic.
Sometimes a challenge is the right control. Often it is not the only control, and it is a poor one if it is the first and last thing you add. We will not drop a widget on every page and call the job done.
Yes. Many teams already pay for a network filter that is tuned for a different era. We will use what you have when it can express the rules, and we will say when the form needs something closer to the request.
The URLs of the flows, a sample of the junk you are already receiving if you have it, and any current rules. Send that through Contact.