Project · In production

From research to production: bitpull.ai

bitpull.ai is the production system this lab feeds. It is where the voice, realtime, conversational and tool-use research stops being a diagram and starts answering the phone.

Most of what a research lab publishes never has to survive a customer. This one does: NEOB operates bitpull.ai, a commercial platform that lets businesses put AI agents on the channels they already use. That relationship shapes the research more than it shapes the product - it is why our latency budgets are in milliseconds rather than in adjectives, and why a browser-agent experiment ended with us declining to make writes autonomous.

What the research contributed

Each of these is a research area on this site with a production counterpart in the platform. The link goes to the research, not to the feature.

ResearchWhat it turned into
Voice AIThe telephony pipeline: streaming transcription, turn detection, barge-in handling and clause-level speech synthesis.
Realtime AIPipeline overlap and streaming, so the caller-visible gap does not grow with the length of the answer.
AI AgentsNarrow tools with business rules in code, idempotent write operations, and a handover path with context attached.
Conversational AIDialogue state, grounding against a customer knowledge base, and escalation to a person when the agent should stop.
Multimodal AIKnowledge ingestion from websites and documents, including scanned PDFs that have no text layer.
Omnichannel AgentsOne agent definition behind several channel adapters, sharing knowledge, tools and business logic.

What is actually live

Stated conservatively and on purpose. A research site that describes a roadmap as a product is not worth reading, so this list contains only capabilities that are in the shipping product today, and the last row is marked as what it is.

Live

Telephone

Inbound and outbound calls over SIP with the business's own numbers, and transfer to a human.

Live

Website widget

The same agent by voice or text in a widget embedded on the customer's site.

Live

Messaging

Messaging integrations sharing the same agent definition and knowledge base.

Live

Appointment booking

Booking against a real calendar during the conversation, with Google Calendar and Calendly integrations.

Live

Tools and webhooks

Custom tools and webhooks so an agent can call the customer's own APIs and CRM.

Research

Email as an agent channel

Not shipped. Email currently appears as summaries and notifications; an agent-operated email channel is research.

On email

Email appears in the product today as conversation summaries and notifications - not as a channel an agent operates. An asynchronous channel with no possibility of interruption has a different risk profile from a live call, and we treat it as open research rather than as a shipped capability.

Why the platform shape follows from the research

The thesis this lab keeps returning to is one agent, multiple interfaces, shared context. A business should not maintain separate AI systems for the phone, the website and a messaging channel - the channel is transport, and everything that decides behaviour belongs one layer below it.

Customer
PhoneWeb voiceWeb chatMessaging
Agent layer

One agent definition - instructions, knowledge, tools, guardrails

KnowledgeConversation memoryBusiness logicTool registry
Systems of record
CRMCalendarWebhooks / custom APIs
The architecture argued for in the research, as the platform implements it.

That is why the product is not a phone bot with a chat widget bolted on. One agent definition sits behind the adapters, the same knowledge base and the same tools serve all of them, and the channel decides only how a reply is rendered - spoken, or shown with a link attached.

What production changed about the research

The traffic corrected us more than once, and those corrections are the most useful thing about having a product attached to a lab.

  • Three options, not six. We let the agent offer as many appointment slots as the calendar returned. By voice, a caller has forgotten the first option by the time they hear the last. The limit now lives in the tool, not in a request in the prompt.
  • Silence is a failure state. Complaints we had attributed to model latency were about dead air during calendar lookups. Speaking before awaiting the tool fixed a problem that no amount of optimisation would have.
  • Interruption is a state problem. Built in the audio layer first; every bug came from the audio and the conversation state disagreeing about what had been said.
  • Business rules belong in tools. Opening hours, service durations and buffer times in a prompt are suggestions. In a tool they are rules with tests.

Where to go next

If you want the commercial view - pricing, industry pages, a live demo number and the German-language product documentation - that is on the bitpull.ai platform itself. If you want the reasoning, it is on this site, and the two are deliberately not the same content.