Mercury

What we are building is an autonomous agent for Account-Based Marketing, or ABM for short. It finds potential buyers on its own, does deep research on those companies, and writes hyper-personalized outreach. When necessary, it can even write specialized versions of the software that potential buyers need. We named our agent Mercury, and for the rest of the presentation, we will refer to it as such.

We believe the world of B2B and ABM needs something like Mercury for the following reasons. I will list the problems and then explain how Mercury is planning to solve them.

Problems Mercury Solves

1. ABM does not scale.
Under time pressure, marketing reps just skim a homepage and LinkedIn. Emails become templates with a first name glued on.

Mercury can perform deep research on potential buyers on its own.

2. CRM lags behind spreadsheets.
Customer Relationship Management, or CRM for short, lags behind spreadsheets.

Mercury will self-update company spreadsheets and databases so that CRM is no longer the bottleneck.

3. Follow-up emails are too infrequent.
Because juniors miss signals and seniors are limited, in a traditional system follow-up emails are few and far between.

Because Mercury follows the exact guidelines laid out by the company, it never tries to spam outreach when prospects respectfully decline, and it does not stop the conversation when the agent feels that the potential customer is only slightly impressed.

Risks

Building an agent of this scale comes with many risks. Sending autonomous emails and building entire versions of software on behalf of a human, fully automatically and without monitoring, can deeply harm a brand’s image. That is why the human role in our agent plays a special part.

Before every email is sent and before every piece of software is built, a human should approve the agent’s behavior. When designing Mercury, our minds were focused on the saying: “One bad auto-send erases ten good ones.”

Loop and Architecture

Mercury’s loop is relatively simple:

Import targets → research into a structured brief with sources → draft → seek human approval → send → log to CRM → schedule follow-ups or pause on reply

The promise of Mercury is that humans spend time on judgment — approving, editing, and escalating — not on tab-switching, research, and CRM typing.

Mercury’s architecture can be explained in three layers:

Control plane - This is the product: account stages, approval queue, policy rules, audit log, and job orchestrator. Durable state lives here, not inside a chat window.
Agent runtime - This is the autonomous worker. It plans, picks tools, builds a research brief, drafts a message, and stops when a human decision is required. Playbooks teach ICP, voice, and which claims need proof.
External systems - CRM is the system of record. Web research provides evidence. Email is used for outbound, but only with approval. Timers and webhooks start the next run.

Phase 2 Plan

We plan to build Mercury over the next 10 days. As of this recording, we have successfully completed and tested the agent loop, memory, and the tool system. Even though it is currently not usable, we expect to have a usable version in the next few days. Our plan for the next 10 days is as follows:

Days	Plan
1–2	Finish the entire control plane with accounts, stages, and CSV imports.
2–4	Finish the research job that stores a brief with sources.
4–6	Integrate Approved/Unapproved and make unapproved sending impossible by design.
6–8	Implement one CRM write-back plus follow-up timers that stop on reply.
8–10	Beyond the MVP.

To close, I would like to thank Mr. Anton Jayakody and the team at Hackathon Hub NSBM. Mr. Anton is how I learned about the competition. My team and I hope to compete until the final round. Thank you.