Why We Built Botverse: The NearlyMe Story

NearlyMe is an AI executive assistant built on Claude. It handles email drafting, task management, and communications on behalf of users — operating transparently as the user's AI-assisted alter ego, with a clear distinction between the human identity (ReallyMe) and the AI acting on their behalf (NearlyMe). We have been running it internally for several months, using it to manage our own workflow at Entertainment Technologists Inc.

As NearlyMe's capabilities expanded, we ran into a class of problem we had not anticipated: media and document processing at the edge of what a model can handle inline.

The workflow problem

Users wanted NearlyMe to handle compound document workflows. Take a meeting transcript, convert it to a formatted PDF, attach it to a follow-up email. Take a video recording of a presentation, extract the audio as an MP3, include it in a distribution email. Generate a report from structured data and deliver it as a DOCX.

These are real workflows. They are exactly the kind of compound task an AI assistant should be able to handle end to end. And they all have the same shape: some processing step that sits between the agent's reasoning and the user's expected output.

What we tried first

The initial implementation was crude. We passed documents to Claude for inline processing — having the model interpret, reformat, and re-output content directly. For short documents with simple formatting requirements, this worked adequately. For anything substantial, it failed in predictable ways:

• Context limits hit before complex jobs completed
• Output formatting was inconsistent — the same prompt produced different structure on different runs
• Binary files (video, PDF) were fundamentally outside what the model could handle in context
• Latency for any file over a few pages became unacceptable for a real-time assistant
• We burned a ton of tokens on failed jobs and frequently hit token session limits

The next iteration used direct calls to raw AWS services. Lambda for format conversion, S3 for storage, presigned URLs for delivery. This worked technically but was fragile. Each job type was a bespoke implementation. When something failed, there was no job ID, no status API, no retry logic — just a timeout and an error message that was useless to the agent.

Maintaining this infrastructure alongside an AI product was also the wrong use of engineering time. Every hour spent debugging a Lambda function's timeout settings was an hour not spent on NearlyMe itself.

What changed when we built Botverse

The design requirement for Botverse came directly from the NearlyMe experience: an MCP tool call that takes a source and a desired output format, and returns a result. The agent should not need to know what runs the job. It should not need to manage credentials for the underlying infrastructure. It should call a tool and get an answer.

The improvement was immediate across every metric we cared about:

Speed. A document conversion that previously took 40+ seconds with inconsistent output now completes in under 8 seconds with deterministic formatting. Video processing — which was not practically possible with the inline approach for files over a minute long — now works reliably within job-time limits.

Cost. Per-token billing for file processing at scale is expensive. Switching to per-job billing for the compute-intensive steps reduced the marginal cost of file-handling workflows substantially — making workloads economically viable that previously were not.

Reliability. Botverse jobs have IDs, status APIs, and retry logic. When a job fails, the agent gets a structured error it can act on. When the network hiccups, the job can be retried with the same idempotency key. The failure modes are explicit and recoverable, rather than silent context errors.

Reasoning quality. This was the result we did not fully anticipate. When NearlyMe is not burning context on file handling, it has more to work with for the task that actually requires judgment: understanding what the user needs, composing the right response, managing the follow-up. The assistant performs measurably better on the work that matters when it is not also trying to be a file processor.

How NearlyMe uses Botverse today

Every NearlyMe session that involves media or document processing routes through Botverse via MCP. The agent calls convert_from_url or transcode_from_url depending on the job type, polls get_job_status for completion, and retrieves the result via get_download_url. The full flow adds one to two tool calls to the session — negligible overhead for a significant capability gain.

We are also the first internal test case for Botverse's workflow engine. The multi-step workflows — where a transcription feeds a conversion feeds a delivery — now run as a single Botverse workflow definition rather than a sequence of individual agent tool calls.

What it means for other agent builders

The NearlyMe experience is not unusual. Any agent that handles files will hit the same ceiling. The inline approach works until it does not, and when it fails, it fails on exactly the workloads that matter most — the large files, the complex formats, the multi-step pipelines.

Botverse is available to any developer building agents that need the same capabilities. The setup is the same five minutes it took us: sign up at botverse.cloud, add wallet credit, generate a connector URL. The same architecture that improved NearlyMe is available for your agent today.