Putting an agent next to a sales rep --- agent architecture, data model, security/privacy, and cost structure

The first cost measurement from the prototype was about half a cent : $0.0049, or 4,481 tokens, for one short typed answer.

That then leads me to other questions : what does a 30-minute call cost, and what more would the sales rep have to earn to cover it?

I want to walk through what the prototype is made of, what it stores, what can go wrong, and what savings need to be to exceed the costs.

Goal

Give a technical lead and a sponsor one document they can both use to consider this agent approach for their sales enablement challenges.

Working assumption

To start, the agent is a knowledge adviser. It advises and does not act. Text is the default, the knowledge is local and curated, and the rep owns every click.

What the sales rep sees

Before the architecture, here is what this looks like in use.

In this case I run it on one screen. The assistant sits in a narrow browser window in a corner, and the CRM gets the rest. The CRM in these screenshots is a mock, with simulated customer data.

What to notice in the assistant’s window, before a session starts :

• A status row. Elapsed time, tokens and estimated cost are on screen from the first second.
• A standing notice. Prototype only, simulated data, and the region where audio and screen frames are processed.
• Separate controls for the session, the microphone and the screen. The microphone and the screen both start off.
• A frame counter under the screen preview. It shows how many frames were sampled, how many were sent, and the share saved by not sending unchanged screens.

Scrolling down in the same window gives the panel where the guidance arrives.

• Silent by default. Answers arrive as text in this panel. The rep asks by typing, or by saying “Assistant” before a request.
• Voice is opt-in. With “Voice output” ticked, the assistant also speaks its answer.
• The text box says what it is for : asking privately, without speaking over the customer.

Two labels in this panel, “Generated either way” and “Call audio”, come from design decisions I explain in the next section.

Architecture

Everything except the model runs on the rep’s own laptop, next to the CRM. That is why the assistant’s address in the screenshots is a local one.

The agent is built with Google’s Agent Development Kit (ADK 2.8) and runs on gemini-live-2.5-flash-native-audio. The system instruction is about 1,000 tokens.

Three design decisions, and the reason for each :

• One audio stream. So call audio is labelled “Call audio”, not by speaker. I did not attempt speaker identification.
• The model produces audio, and the text comes from transcription. So “mute” is a local discard of the audio. That is what “Generated either way” means under the Voice output checkbox.
• No web search and no vector store. The agent answers from its Open Knowledge Format bundle or says it cannot.

Data model

A knowledge concept is a Markdown file with a header : type, title, description, tags, status, what generated it and when, who verified it and when, and its sources. Its identity is its path. Each folder has an index, and a log records changes.

Provenance is part of the record. Most concepts cite their source grounding content or file.

Trust, read correctly. In this bundle most concepts are stable, some are draft, and some are deprecated, and none carries a verified stamp. Under the format, stable is the default status and trust is derived from verified, so that combination is valid. The fair reading : every answer from this bundle counts as unverified until a person signs off. The agent’s instruction already tells it to say so.

Concept size is a retrieval budget. The knowledge tool returns at most 3,000 tokens. The median concept is about 1,000 tokens and the largest about 1,800, so one concept fits in one return.

The session lives in memory : transcript lines and a budget snapshot (elapsed time, tokens, estimated cost, turns). Audio, video and transcripts are not saved unless a flag is turned on.

Security and privacy, today

Each row says what exists and what is missing.

The staged path : from adviser to an agent that can assist with data entry

Start as an adviser. Once consistency has been shown across many calls, extend the same agent by adding tools one at a time. In ADK a tool is a function registered on the agent, so the mechanism does not change. The safety model does.

What changes at Stage 2. Prompt injection becomes consequential, because on-screen text or call speech could steer an action. Controls I would design first :

• The rep approves the exact change, not a summary of it.
• Each tool gets the least privilege it needs.
• Actions are idempotent and reversible where possible.
• Every proposal and decision is logged.
• Sensitive fields are off limits.

Open question I leave to myself : would an action reach the CRM through an API, or by operating the screen? That choice changes the security model the most. Unfortunately many CRMs have missing APIs that never get around to being developed.

Cost structure

Five buckets :

1. Live session tokens. Audio in, screen frames in, text, audio out. Cost grows with call length, because each turn re-processes the context window.
2. Knowledge. Capture, conversion, review and upkeep. Capture was small : 23.5 minutes of narration plus a short round of written questions.
3. Platform. Hosting, engineering, security review, support.
4. Model lifecycle. Migrating and re-validating when a model is retired.
5. Per-tool cost, from Stage 1 onward. Building, testing and monitoring each action.

The session arithmetic

List prices at the time of writing : audio in at $3.00 per million tokens (25 tokens per second), screen frames at $3.00 per million (258 tokens per second, at one frame a second), text in at $0.50, audio out at $12.00, text out at $2.00.

What I take from it :

• The prompt is not the cost. The screen is. The 1,000-token instruction costs about $0.03 over 60 turns.
• Sending only changed frames matters. It is the difference between about $1.39 and about $0.35.
• Context re-processing is the wild card. If each turn is billed on the whole window at the $3.00 rate, that is roughly $0.48 (20 turns, 8,000 tokens) to $2.88 (60 turns, 16,000 tokens).
• The ceiling. The guard’s one-million-token cap is $3.00 at the input rate. My target was under $5 per 30-minute session.

The economic model

net value per month =
    minutes saved per call x assisted calls x value per rep-minute
  - variable cost per call x assisted calls
  - fixed monthly cost

break-even minutes saved per call =
    (variable cost per call + fixed monthly cost / assisted calls)
    / value per rep-minute

A worked example with hypothetical inputs : 600 assisted calls a month, $1.00 per rep-minute, and $2.00 per call in tokens and hosting.

• With 10 hours of upkeep, break-even is 3.25 minutes saved per call.
• With 2 hours of upkeep, it falls to 2.25 minutes.
• At $5.00 per call, the same two cases are 6.25 and 5.25 minutes.

The point of the example : the token bill is not what decides it. Upkeep and the minutes-saved assumption do, so it’s important to immediately create the measurement instrumentation needed to make a decision early on.

What I would measure

• Minutes of document hunting per call.
• Corrections and rework after the call.
• Time for a new rep to reach their first unassisted order.
• Coach hours per new rep.
• The negative channels too : time spent reading the assistant, and the cost of a wrong answer.

The plan : a baseline, then a stepped rollout so some reps act as the comparison group. The automated tests in the repository check retrieval and calculation rules, not helpfulness, and the mock-call scores were manual. So the first job is a repeatable question set and a scoring rubric.

Risk or limitation (for now)

• Costs are unmeasured on real calls. Benefits are unproven.
• The knowledge is unverified.
• The model has a retirement date, and the platform is still moving.
• This describes the build at the time of writing.