Most B2B outbound fails not because of bad copy or wrong targets — but because of wrong timing. You're reaching out to companies that aren't ready. The budget isn't there. The problem isn't active. The moment hasn't arrived yet. Signalbase is built around catching that moment. When a company raises a round, a key hire joins, or hiring patterns shift — Signalbase detects it, verifies it, and delivers it in under a minute. The idea is simple: reach out when something actually changes, not because a name is on a list. I wanted to understand what that system actually looks like underneath. So I connected with Georgi Furnadzhiev, CEO of Signalbase (trysignalbase.com), to understand their product more deeply.
Why I called Georgi
My background is in software engineering and data systems — shaped by close to two years building at Amazon and advanced research at IIT Bombay. I spend most of my time now thinking about one specific problem: what does a production-grade agentic system actually look like, as opposed to the version that works in a demo.
Signalbase caught my attention because the product looked deceptively simple. A clean dashboard. Funding signals. Job change signals. One-minute delivery. That kind of surface simplicity, in my experience, usually means a lot of invisible work underneath.
Before the call, I tried to map their architecture myself — drew out what I thought the agent pipeline looked like based on the website and the dashboard. Then I got Georgi Furnadzhiev, their CEO, on a call and asked him to throw some light on it.
He did. And those deeper understandings are what this post is about.
"It's one thing to source accounts that are in a database. It's another thing to have a live stream of data."
— Georgi Furnadzhiev, CEO of Signalbase
What a signal actually is
I asked Georgi for his working definition early — not the website version.
"Signals are pieces of information that bring context towards why your solution is becoming more relevant for that person on the other side."
The word that matters is context. A LinkedIn comment is not a signal. A funding round alone is not a signal. What makes something a signal is what it implies when combined with other things happening at the same company at the same time.
A Series B. A new VP of Sales hired six weeks later. Three enterprise AE job postings going live the week after that. Those three things together tell you a company got money, hired the person to lead revenue, and is now building the team to close deals. They are in motion. That is when you reach out.
Without knowing which combination of events means someone is in your buying window, no signal provider can help you. That part is still your job.
For Founders
Write down your custom signal before paying for any data. What needs to be true simultaneously for a company to be ready to buy what you sell? That specific combination matters more than the number of signals in anyone's database.
Understanding architecture
My sketch had the pipeline as a tree. A planner agent branching out in parallel to a validation agent and a deep dive agent. Faster, more efficient — the obvious design.
Georgi stopped me when I showed him. "It's not a tree. It's a waterfall. Planner, then validation, then deep dive, then normalisation. Sequential. Because in that case you enforce it."
I sat with that for a moment. Parallel is usually better in engineering — faster, more scalable. But for a verification pipeline where quality is the entire product, sequential enforcement solves a specific problem. The deep dive agent should not enrich a signal that validation would have caught as false. Running them in sequence prevents that class of error entirely.
The pipeline:
01 — Event detection Continuous monitoring across LinkedIn, Twitter/X, press wires, hiring portals. Event-driven extraction — not cron jobs watching specific accounts. Something changes, the system picks it up. One to five minutes from real-world event to capture.
02 — Planner agent Receives the raw signal, determines signal type, routes it into the verification waterfall.
03 — Validation agent LLMs run independent web queries to find coverage across multiple sources. Confidence score computed. Below 80% — the signal does not go out.
04 — Deep dive agent Company-specific enrichment. A job change signal triggers scraping of both the old company and the new one. Investors found, matched to the investor database. One signal cascades into a full profile update on both sides.
05 — Normalisation Consistent schema across all signal types. Deduplication. Source links attached — the customer sees exactly what evidence backed each signal.
06 — Delivery REST API, webhooks, HubSpot, CSV, dashboard. Total time from real-world event to structured JSON in your system: roughly one minute.
| | | |---|---| | ~1 min | event to structured JSON | | 80% | confidence threshold before release | | 60/40 | agentic AI vs traditional scraping |
The human who became the agent
Early on, the validation step was not an agent. It was Georgi.
He sat there reading every signal that came out of the scraper. Matching titles. Checking whether the funding round amount was correct. Verifying investor names. One by one. Every single one.
Then they built an agent trained on exactly what Georgi was doing. Not a general verification agent — an agent trained on the specific judgment calls he made manually, the specific checks he ran, the patterns he caught. "It automated my work," he said. "And now we know it's reliable."
That is the pattern. Find the human doing repetitive judgment work. Map every decision they make. Build an agent that replicates that specific logic. The narrower the task, the more reliably an agent can own it.
For AI Engineers
If you are building agentic systems and struggling with reliability — find the human who would do this task manually and interview them. Not for requirements. For judgment logic. The agent needs to replicate the reasoning, not just the output format. That is where most implementations miss.
The miss rate — the question behind the question
Every scraping system misses signals/ relavant piece of information . The question that matters is whether the miss rate gets smaller over time — and whether anyone is actually measuring it.
When I put this to Georgi, he did not deflect. "Some people say you guys missed a few funding rounds. It's only normal. We're a growing company trying to match the servers of someone who's been ten years in the market."
But then he described the mechanism. Every job change signal triggers a cascade. The system does not just log the change — it scrapes both the old company and the new one, finds their investors, matches those investors to the investor database, and updates everything. One signal closes multiple gaps it did not know were gaps.
"You unlock one door and then a new stream of data floods in."
— Georgi Furnadzhiev
The other mechanism is customer feedback. When a customer finds something the system missed, they surface it. The team adds the source. Georgi gave a specific example — a news outlet in the Nordics, written in a language their scrapers were not monitoring. A customer flagged it. It got added. Now it feeds signals for every customer on the platform.
The customers are doing source discovery for the system without realising it. That is not a workaround. That is a feedback loop designed into the architecture.
For AI Engineers
Feedback loops are infrastructure, not a feature. If customers can surface what the system missed, and the system learns from that, coverage compounds over time without you having to anticipate every edge case upfront. Most teams build the pipeline first and add feedback later. It should be the other way around.
The 15 articles he took down
Since becoming CEO, Georgi has pulled 15 articles from the platform. Four were premature — the funding was real, but someone had leaked before the official announcement. Signalbase picked it up, published it, then pulled it when the timing became clear.
"Quality first. People will only stay with us if we take care of quality."
The false positive problem is harder than the tooling suggests. An LLM reading a LinkedIn post that says "thrilled to announce our Series B" will often mark it confirmed. LLMs are trained to be helpful and coherent. They are not naturally skeptical. They are bad at expressing appropriate uncertainty about real-world claims.
Signalbase keeps the LLM out of the final verdict. The LLM searches for coverage. The confidence score is computed from how many independent sources confirmed it. The LLM does research. Deterministic logic makes the call.
For AI Engineers
Know which decisions tolerate hallucination and which do not. LLMs are useful for research, synthesis, language interpretation. For high-stakes factual claims — gather evidence with LLMs, then let deterministic checks reach the verdict. If you have tried the other way, you already know what happens.
What signals can and cannot do
At some point I asked Georgi what he tells customers who bought signals and are not seeing the results they expected.
"Signals are just contextual tools for you to know who to target. How to close the account is a completely different game."
Three things determine whether a signal-triggered outreach closes. Timing — whether you reached out at exactly the moment they were actively thinking about the problem. Copy — how specifically the message references the signal. Brand — whether they have seen your name enough times that they do not immediately ignore it.
Signals help with timing. They do not help with the other two.
Where the pipeline ends
Signalbase ends at the webhook. Verified signal, enriched company profile, structured JSON, delivered. What happens next is outside their system.
For most teams, what happens next looks like this. The signal lands in a Slack channel. Someone screenshots it into a HubSpot note. A rep opens a Google Doc to draft an outreach message. The draft circulates in another thread. Someone edits it. The final version gets copied into a LinkedIn DM or an email sequence by hand.
The infrastructure scaled. The judgment did not. The agent pipeline runs at one-minute latency. The response runs at one-to-three days, because humans are the bottleneck between the signal and the action.
Georgi tried to close this gap himself. Built an agent to handle his own high-value outreach — trained on his previous messages, his tone, his approach per account type. It did not work. "There are just some nuances the agent couldn't catch — my tone of voice, the particular angle I want to go after. It feels very unnatural."
He still does that manually. And he is the CEO of a signal infrastructure company.
Most teams have signals landing cleanly on one side and humans gluing things together on the other. The gap between them is where time gets lost, context gets dropped, and the moment passes.
What never makes it into coverage
I always end these conversations the same way. What is one thing about what you are building that almost never makes it into coverage — but should?
Georgi: "The general market realization of how hard it is to do what we do. Contextualization and sourcing looks easy. It's very hard. Especially when you need to match data points to one another."
He is right. The product shows you a list of companies with signals. It looks like a well-maintained spreadsheet. What it does not show is the waterfall verification pipeline, the LLM coverage search, the cascading enrichment that fires on every signal, the confidence scoring, the source links, the agent that replaced Georgi doing manual QA one signal at a time.
None of that is visible. You just see the list.
That invisibility is the point. The best infrastructure disappears. The output looks effortless. The work of making it look effortless is where the moat lives — and it takes years to build, not months.