A sensor is the right tool when your software should react: an acquisition lands, a webhook fires, a workflow starts. But a lot of the people and agents who use Evinor don’t want to be interrupted. They want to ask, at a time of their choosing, what happened that matters to me since I last looked?

That is a beat. Today we’re launching Beats: a saved set of things you care about that Evinor keeps matching for you, recording every event that qualifies into a log you read whenever you like. No endpoint to host. No signature to verify. Nothing to keep online.

The Beats page listing three beats with entries, credits and spend caps for the month.
The Beats page: every beat you own, with what it collected this month. Example data.

Why we built it

Sensors push. Each sensor holds one filter and delivers each match to a webhook as it happens. That is exactly right for automation, and awkward for everything else:

  • You need somewhere to receive it. An endpoint you stand up, secure and keep running. For an analyst, or an AI agent that wakes up once an hour, that is a lot of infrastructure for “tell me what’s new.”
  • One filter per sensor. “Anything involving OpenAI, or any product launch reported by two outlets, or any executive change at these three companies” is three sensors and three endpoints.
  • Search answers a different question. Event search is recomputed every time you run it. It is great for looking something up and poor as a running record of what has been relevant to you.

A beat takes the same matching engine that powers sensors and removes the delivery step. Matches accumulate instead of being pushed.

What a beat is

A beat has a name, one to twenty clauses, and a monthly spend cap. An event that matches any clause becomes an entry on the beat, exactly once. You read the entries back by time window, or by asking for everything since your last read.

Sensors push. Beats accumulate. A sensor tells you the moment something happens. A beat remembers it for you and waits until you ask.

Describing what matters

A clause is a filter, using the same vocabulary as sensors and event search. Clauses come in two shapes:

  • Entity clauses follow companies, people or whole lists of them. “Everything involving my portfolio watchlist.”
  • Event-type clauses follow a kind of event, optionally narrowed. “Funding rounds of $50M or more among climate-tech companies.”

Because clauses are OR-ed, one beat can hold a whole point of view:

// A competitor beat
Entity        Rivals (5), involved
OR
Product launch
OR
Leadership change  Rivals (5)

Two controls decide how strict a clause is:

  • Involved versus mentioned. Should the entity merely appear somewhere in the event, or actually play a role in it? A company that is mentioned in a story about a rival’s launch is not the same as a company that launched. Entity clauses default to participants.
  • Minimum reports. Require that several distinct outlets have reported the event before it counts, from one to ten.

Creating a beat, with a preview

The create wizard walks through five steps: start, entities, event types, spend, review. A live preview runs beside every step, so you see roughly how many events from the last 30 days each clause would have caught, before you save anything. If a clause is too broad or too narrow, you find out while you can still fix it.

The new-beat wizard on the Entities step, with two entities chosen and a preview showing 47 unique events over 30 days.
The create wizard. The preview rail shows what each clause would have matched in the last 30 days. Example data.

When you save, the beat doesn’t start empty. It looks back over recent history and fills itself with existing matches, so the first thing you see is a useful log rather than a blank page. That backfill is free and its depth depends on your plan.

Entries, and why each one is there

An entry is a single event on a beat, with its type, the entities involved, how many sources reported it and when. Every entry can answer the question a log should always be able to answer: why is this here? The Why disclosure shows which clause matched.

A beat’s Entries tab with events grouped by day, one row expanded to show the clause that matched it, plus superseded and backfilled badges.
The Entries tab. Each row can show which clause matched it. Example data.

Events evolve. When two incidents turn out to be the same event and are merged, the beat doesn’t quietly delete the older entry. It marks it as superseded and points to the survivor, so your history stays honest and you are never charged twice for one event.

Beats and sensors

They share one matching engine, so a filter means the same thing in both. The difference is what happens after a match.

Delivery

A sensor pushes each match to your webhook or Slack as it happens. A beat delivers nothing: matches are recorded, and you pull them. That is the whole reason a beat needs no endpoint.

Shape

A sensor holds a single filter. A beat holds up to twenty OR-ed clauses, so related interests live together instead of being scattered across many sensors.

Cost

A sensor is charged per match. A beat is charged per entry recorded, once per event, with the amount set by the event type. Reading, listing and previewing are free, and so is the backfill. A beat that finds nothing costs nothing.

Who it’s for

Use a sensor when software should act the moment something happens. Use a beat when a person or an agent should look on their own schedule. Plenty of teams will use both: a sensor on the three events that must trigger a workflow, and a beat for everything worth knowing about.

Built for agents

Beats are available over the REST API and over MCP. An agent can create a beat, then check it on whatever cadence suits it. The poll_since cursor means each read returns only what is new:

const since = store.get("beat_cursor") ?? "";
const page = await mcp.call("get_beat_entries", {
  beat_id: "<your beat id>",
  since,
});
// page on with get_beat_entries_continue while has_more
if (page.data.some(isRelevant)) await brief(page.data);
store.set("beat_cursor", page.poll_since);

An agent can create a beat and read its entries, but changing, pausing or deleting one stays in the app and the REST API. Anything that alters or unbounds existing spend is deliberately not one tool call away.

The Agent access panel on a beat showing its ID and a REST curl example for reading new entries.
The “Read as agent” panel on a beat shows the exact calls for REST and MCP.

Predictable spend

Because a beat spends on its own, every month, it carries a monthly spend cap. When the next entry would take the month past the cap, the beat pauses instead of overspending. Entries already collected stay readable, and the pause shows up as a gap, so a reader can tell that a window is incomplete rather than assuming nothing happened.

A paused beat resumes by itself at the start of the next month. To continue sooner, raise the cap and resume it.

A beat paused because it reached its monthly spend cap, with Resume and Raise cap buttons.
A beat paused by its spend cap. Raise the cap and resume to keep collecting. Example data.

What beats don’t do (yet)

  • No push delivery. There is no webhook, email or digest for a beat. If you need to be told, use a sensor.
  • No sharing. A beat belongs to one account.
  • Entries are fixed once recorded. A later correction to an event does not rewrite an existing entry.

Try it

Beats are live now. Create one from the Beats page, or read the API documentation to create one from code or from your agent. Start with a single clause you already care about, check the preview, and see what a week of reality looks like.

Taggedbeatssensorsagentsproduct
AF
Arman Fatemi
Building Evinor