Agent

Agent watches the same data this documentation describes and tells you when something you asked about happens. It lives at agent.debyko.com and is open to every DEBYKO account, the free one included: sign in with your email and the code it receives, press New rule, write the condition in DQL, choose how often it is checked and where the notification goes: any number of your channels, Telegram chats and webhooks mixed, set up under Channels.

Every channel a firing reaches is one notification: a firing sent to 1 channel is 1, to 10 channels 10, and a retry of the same delivery is not counted again. Notifications are counted per account per UTC day; over the plan’s daily notifications a firing is recorded as “not delivered: daily notification limit”, the rule keeps running, and delivery resumes at 00:00 UTC.

How many rules a plan runs, how often a rule may be checked, how many webhooks and Telegram chats the account may hold and its notifications a day are on the pricing table, read from the same plan table Agent enforces.

It is a client, not an endpoint

There is no alerts endpoint in the reference, and there will not be one. There was: an earlier draft of the API had alert rules, a webhook payload and an armed/fired state, and change set 04 removed all of it — see the changelog.

The reason is worth stating, because it is the difference between a platform and a product wearing one as a costume. An agent is a client with its own key. It stores what a user configured — the query, how often to run it, where to deliver — calls POST /v2/screen like anybody else, keeps its own record of what has already fired, and sends the notification itself.

The API does not know whether a person or an agent is asking. That is deliberate. It means the agent has no privileged path inward, and it means that if the agent ever needs something the language cannot express, the answer is to fix the language rather than to add a private door — because if the agent needs it, so do you.

What this means for you today

A rule is a query. Not a query-like configuration language that resembles one: the same DQL, the same three statuses, the same provenance on every value it fires on.

So you can write and test a rule before you save it in Agent:

any(venues where funding_8h > 5bps and status(funding) = present) where base = BTC

Send it to POST /v2/dql/parse — no key, no market data read — until it parses. Run it on POST /v2/screen with include_unknown: true and look at what came back unknown; those are the instruments the rule cannot decide, and they are where a naive alert would either fire wrongly or stay silent wrongly. That query is what you paste into Agent.

If you would rather decide on your own side, the stream sends every change as it arrives — including a change of status with no new value — and a small program of yours decides what is worth acting on. With Agent, the watching is DEBYKO’s: Agent runs your query on your schedule and sends the notification, and a program on your side that receives the webhook acts on it only for the tags you switched on.

When a watch fires

A watch fires when Agent has seen its condition false — with every value it reads present — and then true, no more than the watch’s window apart. Unknown is not a sighting, and neither is a false that holds only because a value is missing or stale: neither fires, re-arms a watch that has fired, or arms a watch that has never been seen false. A condition that turns true because data came back therefore fires only if Agent saw it cleanly false shortly before the data went away — and then the notification says how long Agent could not see. A new or edited watch fires only after it has first been seen false.

What it does not watch

Agent watches market data: things expressible in DQL, which means things a venue published, with a venue, a receipt time and an age attached.

It does not watch machines, containers, disks or build pipelines. There is no DQL field for “how long since the host answered”, and inventing one would break the invariant the whole language rests on — that every value is a measurement somebody published, with its provenance. Operational health has its own tools and its own alerting; mixing the two would make both harder to trust.

We are its first user

Not a gesture. DEBYKO’s own collection monitoring is written as DQL rules, to run through Agent with an ordinary key against this same public API.

That is the strongest test there is. The platform’s SelfCheck service watches a synthetic segment end to end, which proves the pipe is intact — it does not prove that real data from real venues is still arriving. This does:

any(venues where status(funding) = stale and age(funding) > 10m)

A rule that wakes somebody at night for nothing gets fixed. A customer who gets woken for nothing just leaves.