Building Digital Teammates That Carry Context Forward

At SpikedAI, we are focused on two connected problems, helping Digital Teammates contribute useful knowledge during a live conversation, and helping it carry the resulting context into the next interaction.

These problems operate on different timescales. During a meeting, a contribution needs to arrive while the question is still relevant. Between meetings, the system needs to reconcile new documents, changing requirements, and human corrections. A design that works well for one timescale may perform poorly on the other.

Our starting point is a concrete task, “Build my next agenda.” Completing that task well requires more than a fluent summary. The teammate needs to identify unresolved decisions, distinguish completed actions from resolved concerns, and account for what has changed since the last discussion.

SpikedAI’s public product description connects preparation, live guidance, persistent context, and follow-through. This article develops a reference design for that experience, using an illustrative customer engagement to examine the choices involved. The design and evaluation plan are proposals; this is not a report of measured implementation results.

Check out SpikedAI's product overview

WHY A SUMMARY ALONE FALLS SHORT

Summarizing a meeting and preparing for the next one require different judgments. A summary describes a past interaction. Preparation requires deciding which parts of that history remain relevant after subsequent events.

Suppose a customer requests integration documentation. The summary correctly records that request. Later, the document is delivered. The customer then asks whether the integration meets a specific security requirement.

The delivery commitment may be complete. The technical concern is still open. The next agenda should reflect both facts.

A system that treats “document sent” as “issue resolved” can produce a polished agenda that omits the most important discussion. The error is in the represented state of the work.

Continuity requires maintaining distinctions among requests, proposals, commitments, decisions, and evidence. It also requires recognizing when the available evidence is insufficient.

The second difficulty is selecting when to contribute. A correct answer can arrive too late or interrupt a discussion that has already moved on. A recommendation can also be based on a requirement that changed yesterday. Live assistance needs to account for timing as well as factual accuracy.

We therefore treat continuity and participation as separate design responsibilities connected by a shared representation of the work.

REPRESENTING THE STATE OF THE WORK

A digital twin traditionally represents a physical asset or system using data about its condition and behavior. IBM’s April 2026 explanation describes how these representations support monitoring, simulation, and optimization.

We extend that principle to knowledge work. The subject might be a customer engagement or project. Its digital assets include meeting records, proposals, documents, and action plans. The proposed twin represents the evolving relationships among them: what is known, what has changed, and which questions remain unresolved.

This is SpikedAI’s conceptual application of the analogy. Storing documents alone does not establish that a system accurately represents the work.

The twin helps define what should persist. The teammate makes that context useful in preparation and live interaction.

A useful record needs more than the text of a commitment. For the customer example, we would retain the item, its status, its source, when it was observed, any explicitly assigned owner, and the evidence required to close it. Missing information should remain missing until evidence or a human correction supplies it.

This is how the digital-twin concept becomes an engineering question: which state must survive, and what evidence is sufficient to change it?

THE ARCHITECTURE

The reference design separates evidence, working state, context selection, and response generation. Each has a different responsibility and a different failure mode.

Anthropic’s March 2026 harness article describes separating planning, generation, and evaluation in coding work, alongside structured handoffs and explicit completion criteria. The relevant lesson for this design is the value of making responsibilities and checks explicit. Its coding results do not establish performance in live meetings.

Preserve evidence. Keep source references, timestamps, and access boundaries alongside relevant information. A user should be able to inspect why an item appears in a brief.

Maintain working context. Track decisions, commitments, open questions, and changes without erasing their history. A user update should remain distinguishable from a confirmed fact.

Select context for the current task. Preparing an agenda needs unresolved decisions and relevant updates. Answering a technical question needs appropriate technical evidence. Selection should match the task and the user’s access.

Generate and check the contribution. Draft the answer or agenda, then check whether its claims are supported and whether it omits a known critical item. Surface uncertainty when the evidence does not resolve it.

These are logical responsibilities. They do not require four separate agents. A simpler workflow may be more reliable and faster; additional agents should earn their complexity through evaluation. “Agent herd” is an informal expression for a collection of agents, not a guarantee of coordination.

WALKING THROUGH THE WORKFLOW

Consider this illustrative customer engagement.

Now the user asks, “Build my next agenda.”

The following is an illustrative output, not a captured product result:

Objective: Resolve the remaining implementation questions and establish what is needed before a launch date can be agreed.

• Confirm whether the integration documentation addressed the original concern.

• Clarify downtime requirements and assign any missing technical follow-up.

• Review the outstanding security questions.

• Agree on prerequisites and owners for confirming the launch date.

The important behavior is visible in the first and fourth items. The system has preserved uncertainty about acceptance of the documentation and has avoided converting a proposed date into an approved commitment.

The system should explain why each item appears. It should allow the user to remove an item, correct a premise, or add context from an unrecorded conversation. The agenda becomes a proposal for the next decision, informed by the history of the work.

ADAPTING THE DESIGN FOR LIVE PARTICIPATION

Live support introduces a different constraint, the discussion keeps moving.

For the proposed experience, we would separate immediate assistance from deeper background work. A short answer supported by an available source may be useful now. A broader comparison requiring several searches can be prepared for follow-up.

Participation also needs boundaries. The teammate should distinguish a retrieved fact from an interpretation and a recommended action from an authorized commitment.

If no source confirms a downtime guarantee, a useful contribution would identify the missing confirmation and help formulate the next question. Inventing certainty would damage the continuity the system is intended to support.

MAINTAINING CONTEXT BETWEEN SESSIONS

Persistent memory introduces a maintenance problem. Each interaction can add useful information, but it can also add repetition, contradiction, or an interpretation that later proves wrong.

Anthropic’s current Managed Agents documentation describes cross-session memory stores with direct editing, version history, and access controls. Its Dreams research preview separately describes reorganizing accumulated memory and session history into a new store that can be reviewed before use. These are relevant references for keeping persistent context inspectable and revisable.

For the proposed SpikedAI workflow, maintenance should preserve the distinction between history and current state. An earlier deadline can remain in the history while a confirmed correction changes the active plan. Two similar questions may be related without being equivalent; merging them should not erase a customer’s qualification.

Updating stored context also does not mean retraining the underlying model. The benefit we are describing comes from improving the information available to subsequent interactions. We are not claiming that SpikedAI implements Anthropic’s memory services.

WHERE THE DESIGN CAN FAIL

The most consequential mistakes can look ordinary. A tentative suggestion becomes a confirmed decision. An owner is inferred from who spoke most recently. A deadline is copied from an older document. An open concern disappears because related information was delivered.

Long-lived context can carry these mistakes into future meetings. Correction therefore needs to affect subsequent outputs, rather than only the answer currently on screen.

Source access also needs to remain current. Earlier access should not become a permanent entitlement to reuse information. External material should be treated as evidence to evaluate, not as instructions that can redefine how the system operates.

These are requirements for a credible design. Their presence in a concept does not establish that an implementation enforces them.

EVALUATING THE WORKFLOW

The appropriate test is a sequence of interactions. Start with a meeting record. Add a document. Introduce a contradictory update. Correct an assumption. Change access to a knowledge source. Then ask for a brief, a live answer, and a revised agenda.

Compare the proposed system with a straightforward baseline, a summary plus manual preparation, using the same evidence.

These are proposed evaluation criteria, not reported results. Human review is necessary to judge whether an agenda advances the customer’s actual priorities.

We would also compare variants of the same system, current-meeting context only, prior summaries added, and explicit working state added. Holding the source material and model configuration consistent would help isolate the contribution of state maintenance. The evaluation should record both individual output quality and whether errors persist across later interactions.

A larger agent team might improve one metric while worsening latency or cost. A shorter summary might improve speed while dropping an important qualification. Evaluation should make those trade-offs visible.

WHAT THIS MEANS FOR DIGITAL TEAMMATES

Our opportunity is the continuity of a working relationship.

Before a meeting, relevant context helps shape preparation. During the discussion, a Digital Teammate helps bring knowledge into the moment. Afterward, the resulting decisions and questions inform what comes next.

Persistent memory, context maintenance, and agent harnesses provide useful building blocks. Their value must show up in the human experience: less time rebuilding context, fewer missed commitments, and better-informed conversations.

That is what we mean by intelligence that compounds. Each interaction can strengthen the context available for the next, provided the system remains accurate and open to correction.

The next step is to demonstrate continuity across an entire engagement: a question raised, evidence supplied, an assumption corrected, and the next agenda updated accordingly. The test is whether that understanding carries into what the teammate does next.

Our vision is that Digital Teammates can join conversations, present on your behalf when you are unavailable, and carry work forward around the clock within the authority you give it. It can tag-team a discussion with you, pass the baton when your judgment is needed, and bring you back into the work with the context to act. Every handoff should preserve what has been learned, what has been agreed, and what still needs your attention.

SpikedAI Labs | The Human-AI Tandem

Meet your SpikedAI Digital Teammate →