Product Roadmap · June 2026

Fixing the foundations under our agents

Today our agents run on shared infrastructure that cannot isolate, scale, or cap a single run. This month moves the agent loops onto an isolated sandbox runtime, rebuilds the core agents and workflows on top, stands up the read-through intelligence store, and ships the Stripe billing system.

Themes 4P0 8P1 5Spine Sandbox runtime

Now · runtime + workflows→Next · intelligence store→Later · Stripe billing

Overview

now · next · later

This month is about fixing the foundations under our agents. Their workflows have plateaued and every lookup re-pays for data we have already seen. The work below tackles these in order, foundation first - the sandbox runtime is the spine, the workflow redesigns ride the migrated pipelines, the intelligence store reads through what those agents learn, and the Stripe billing system turns usage into revenue. The knowledge base, assistant, and per-action credit tracking that build on this foundation move to the July roadmap.

Themes

one foundation, three riders

P0 priorities

runtime · workflows · billing

P1 priorities

data store · billing

Foundation

sandbox runtime

Now · P0

Theme 1Agent runtime & core agents
Theme 2Workflow improvements

Next · P1

Theme 3Intelligence data store

Later · P0 → P1

Theme 4Billing & subscriptions

Agent runtime & core agents

now

P0P0

Every agent runs inside the same Celery workers as fast background jobs, so long agent loops and short jobs fight for the same slots: jobs back up when agents are busy, a crashing or out-of-memory agent can take a worker down, and nothing caps a run’s memory, time, or cost. Moving the agent loops onto an isolated sandbox runtime fixes that without changing the workflow logic, and it is the foundation for the rest of this roadmap - the Theme 2 redesigns ride the migrated pipelines, and the runtime’s tracing makes the per-action credit tracking on the July roadmap possible.

Migrate agent execution off Celery to a sandbox runtime

Choose the runtime, define one common execution contract, prove it with a pilot agent, then cut each agent over flow by flow and retire the old in-Celery path.

Build the core agents

On the new runtime, stand up the small set of reusable, single-purpose agents that the more complex workflows compose from:

Company sales-signal search agent
People sales-signal search agent
Company enrichment agent
People enrichment agent

Theme 1: migrating agents from shared Celery onto an isolated, capped, traced sandbox runtime, with four reusable core agents built on it — Migrating agents from shared Celery onto an isolated, capped, traced sandbox runtime, with four reusable core agents built on it.

Workflow improvements

now

P0P0P0P0

The agent workflows grew incrementally under the old Celery and Agno constraints, and quality has plateaued: Headhunter leans on a single email provider and discards company data it already fetches, Sonar coverage is thin, and the old harness makes it hard to see why a weak run underperformed. With agents on the sandbox runtime and real tracing, we can redesign each workflow, broaden its data sources, and tighten error handling to lift result quality - and build new capabilities like people signals on top.

Workflow design improvements

Use the new runtime and its tracing to tighten step contracts, error handling, and the retries that were awkward under Celery.

Sonar workflow redesign

With Sonar on the sandbox runtime, redesign its workflow and add data sources to improve the quality and coverage of its search results.

Headhunter workflow redesign

Once Headhunter is migrated, redesign its workflow and add more data sources to lift search-result quality: more people, more emails (sources beyond Hunter, plus email-pattern inference), more accuracy, and richer company detail (much of it already fetched today but discarded).

People signals

A new agentic workflow that searches people for sales signals - job changes, newly published posts, promotions, funding, and other buying triggers - and surfaces them for timely outreach. Lay the people data model the signals attach to, then build the signal-detection workflow on top.

Intelligence data store

P1P1

Every company or person lookup re-calls paid enrichment providers (Exa, Parallel, Firecrawl, Hunter, Apollo), re-enriching entities we have already seen, so cost scales with usage and nothing we learn is retained - when a new sales signal fires we pay again for known data. A private, deduped, provenance-tracked intelligence store that every source writes into fixes that: repeat and signal-driven lookups read from our database instead of a paid API. It sits beside the CRM, not inside it - CRM stays the system of record for workflow state, while the store holds the global knowledge of who companies and people are.

Stand up the company and people intelligence store

Design and build v1: canonical company and person entity models, source ingestion with provenance and confidence, dedup and conflict resolution across providers, freshness tracking, and the PII, RLS, and erasure model. The Theme 1 core agents write into it as they run.

Read-through enrichment and signal storage

Serve company and people data from the store first, calling a paid provider only on a miss or when a record is stale, so repeat and signal-driven lookups stop re-paying. Store, score, and route person- and company-level sales signals out of the same layer.

Theme 3: a read-through intelligence store that serves company and person data first and only calls paid providers on a miss or stale record — A read-through intelligence store that serves company and person data first and only calls paid providers on a miss or stale record.

Billing & subscriptions

later

P0P0P1P1P1

Billing turns usage into revenue. We integrate Stripe end to end - subscription plans through Checkout and the hosted customer portal, a payment method on file via Stripe Link, one-off usage-credit purchases, optional auto-reload when the balance runs low, and an invoices view - mirroring a modern usage-based billing surface. It stands on Stripe’s own metered-usage records, so it ships independently of the per-action credit tracking landing in July; the two reconcile once that work lands.

Stripe Checkout + customer portal

Stand up subscription plans through Stripe Checkout for signup, and the hosted customer portal for plan changes, cancellation, and auto-renew. Sync plan state back via webhooks.

Payment method on file (Stripe Link)

Capture and let users update the default payment method through Stripe Link, surfaced in a Billing settings panel.

Usage-credit purchases + balance

Sell usage credits as one-off top-ups tracked as a Stripe credit balance and shown in-app, reconciled against per-action credit tracking once that lands in July.

Auto-reload

Let users opt into automatic credit top-ups when the balance drops below a threshold, charged to the payment method on file.

Invoices

List paid and open invoices with downloadable PDFs, kept in sync with Stripe via webhooks.

Theme 4: a Stripe billing system - Checkout and customer portal for plans, Stripe Link for the payment method, usage-credit purchases drawing on a Stripe-tracked balance, auto-reload, and invoices — A Stripe billing system: Checkout and the customer portal drive plans, Stripe Link holds the payment method, usage-credit purchases draw down a Stripe-tracked balance, and invoices sync back via webhooks.

KEYThe through-line

One move unlocks the rest: get the agents onto an isolated, traced sandbox runtime. The workflow redesigns ride the migrated pipelines, the intelligence store reads through what those agents learn, and the Stripe billing system turns that usage into revenue. The knowledge base, the chat assistant, and per-action credit tracking build on this same foundation - they carry into the July roadmap. Foundation first.