A UK company has 14 days to tell the registrar that a director has joined or left, so an agent that reads the register overnight can write to an account about news that is already two weeks old. You avoid that failure with the setup around the agent: a watchlist of target accounts, a source that pushes changes, an events table that stores three dates per event, and an approval step before any message goes out.
Pick 50 accounts and the events worth a call
Start small. Drimble’s guidance on company monitoring recommends watching your top 50 target accounts and alerting only on “phone-worthy” events: officer changes, new sites, status changes and capital events. A longer list is easy to build and hard to act on. My take is that an agent makes a noisy watchlist worse, because it drafts a message for every event you hand it.
Drimble’s guide to webhooks and signals for AI agents lists the events most worth wiring up: incorporations and status changes, registered-address moves, director appointments and resignations, new filings, job postings and local news mentions. Pick the two or three that match what you sell. Add the rest only after the first ones earn replies.
Connect to the registers that publish changes
If your accounts sit in one country, go to the source. Companies House runs a Streaming API that pushes changes over a long-running HTTP connection, with separate streams for company information, filing history, insolvency cases, charges, officers and persons with significant control. Each event carries a timepoint, so a client that drops its connection can resume where it stopped, although the rewind window is limited. Each account gets two concurrent connections, which suits a single listener feeding a queue.
Cross-border lists are harder, because every register has its own format and its own publishing rhythm. An aggregator earns its place here. Drimble monitors official registers in ten markets, from the UK and Ireland to Canada and Australia, and delivers alerts by email or through its buying signals webhooks. A daily digest email suits a solo user, teams can push events into the CRM as tasks, and larger operations can consume the webhook feed in their own tooling.
Store three dates on every event
Every signal carries three dates, and your events table should hold all of them. The event date says when the change happened. The publication date says when the register or filing made it public. The observation date says when your system saw it.
The Companies House officers stream shows why the distinction matters. Each record includes the appointment or resignation date next to a published_at timestamp, so you can measure the gap on every change. In the US, a public company has four business days to file a Form 8-K after a director or certain officers leave or join, under Item 5.02. Companies that do not report to the SEC file no 8-Ks at all, so signals about them have to come from other sources.
Drimble’s guidance adds a practical rule: show the observation date next to every event, because some registers publish daily and others weekly. Pass all three dates to the agent. A message about a director who resigned three weeks ago reads differently from one about an appointment filed yesterday, and the agent can only tell the difference if the dates reach it.
Deliver events by webhook and store them first
A webhook pushes each event to you as it happens, so you skip polling. The delivery rules follow the standard playbook. Stripe’s webhook documentation recommends verifying the signature on every request, returning a 2xx status quickly before running any heavy logic, and deduplicating on the event ID. Stripe also does not guarantee delivery order, so build your table to accept events out of sequence.
Drimble’s guide adds the step that matters for agents. Write every verified event into an events table with a stable identifier and a timestamp, and let the agent read from that table instead of from the webhook itself. The agent can then build a daily digest from the table, and you can replay the table after an outage.
Webhooks tell your system that something changed. An agent also needs to ask questions afterward, and that is where the Model Context Protocol fits. MCP is an open-source standard for connecting AI applications to external systems, and the Drimble MCP server works in Claude, ChatGPT and other MCP clients, with every record linked to a company identifier, source and capture date. My take is to use both: webhooks fill the events table, and MCP lets the agent look up the company record behind an event when it drafts.
Let the agent draft and a person send
Give the agent one job. It takes an event plus the account record from your CRM and drafts a short message for the account owner. Drimble’s guidance keeps sending behind one-click approval, and I would do the same until the drafts have proven themselves on real accounts.
Measure the reply rate for each signal type. If messages about director changes draw replies and messages about address moves draw none, remove address moves from the watchlist. Set an expiry on the queue as well. Drimble’s guidance holds that most public signals lose value after about 30 days, so an event older than that should leave the queue unless a person pulls it back.
Treat officer names as personal data
Officer events name individuals. The UK Information Commissioner’s Office states that information about a limited company is not personal data, while a director’s name can be personal data when the information relates to that person as an individual. Decide how your agent stores and uses those names before you switch on officer alerts. Take legal advice on the basis for any message that addresses a named person.
The feed outlasts the agent
The agent is the easiest part of this system to swap. The watchlist, the events table with its three dates and the reply-rate log stay with you, and together they show which events earn a call. Start with 50 accounts, one signal type and a month of data, then widen the feed once the numbers justify it.
The post How to Track Company Signals and Feed Them to Your AI Agents appeared first on DataFLOQ.
