Unified Context™ is Secretar.AI's technology and standard for connecting information, interactions and events about the same entity across integrated systems. Across AI agents, its purpose is to support continuity of understanding as different specialists work on that entity. Shared understanding does not require identical prompts or unrestricted access to every record.
This article is for teams designing agent workflows. It explains a conceptual application of Unified Context through a hypothetical customer handoff. The sequence below describes design responsibilities and evaluation criteria; it is not a specification of released runtime behavior or a guarantee that any pair of agents can interoperate.
Start with an entity, then a task
Imagine a sales agent, a scheduling agent and a support agent helping the same customer at different times. Sales needs the accepted proposal. Scheduling needs the service to be booked and the available times. Support later needs to understand a request to change the appointment.
Passing the entire sales transcript to all three agents would transfer text, but it would leave several questions unresolved. Which customer record is authoritative? Was the proposal actually accepted or merely discussed? Has the appointment changed since the last agent worked on it?
For this example, the proposed starting point is a stable reference to the relevant customer, accompanied by references to the specific proposal and appointment. The organization scope must also be explicit and checked independently of whether identifiers are globally unique. These are implementation requirements to establish, not properties that a model can safely infer from similar names.
A conceptual handoff sequence
| Stage | Information needed | Condition to verify |
|---|---|---|
| Sales completes its task | Customer and accepted proposal references | Acceptance comes from an appropriate source |
| Scheduling begins | Relevant service, booking constraints and current availability | The proposal belongs to the same customer and engagement |
| Booking is recorded | Appointment reference and confirmed state | The booking operation actually succeeded |
| Support receives a change request | Current appointment and relevant history | The original booking has not already been changed |
In this design, the handoff carries enough information to locate the relevant records and understand the remaining task. It should distinguish completed work from intentions. “Customer asked for Tuesday” must not become “Tuesday is booked” merely because the second agent reads a summary.
A context consumer could use MCP to retrieve records, but MCP's host, client and server architecture describes connections rather than this particular business workflow. The relationship would need to be implemented explicitly. MCP architecture overview.
Preserve evidence through summaries
Summaries are useful for orientation: the customer wants an afternoon appointment, the proposal covers a particular service, and a previous conversation explained preparation requirements. They should remain distinguishable from source records that establish contractual or operational state.
Provenance describes the origin and production of information. W3C's PROV family provides models for representing such relationships. That is useful background for thinking about context evidence, without implying that Unified Context implements PROV. W3C PROV overview.
For the hypothetical handoff, retain a reference to the accepted proposal behind the summary of the sale. When support explains why an appointment exists, it should be possible to inspect the booking result rather than relying on one agent's recollection of another agent's message.
Also preserve uncertainty. If the integration cannot confirm acceptance, that absence should remain visible to the receiving agent. Rewording an uncertain statement more confidently is not an update from the source.
Shared context can produce different views
The scheduling agent may only need the service and booking constraints. The support agent may need the current appointment and a short account of the customer's request. Neither task necessarily needs every document that sales handled.
An implementation should define which records and fields each consumer may access and which subset is relevant to its present task. These are different decisions: a record can be permitted but irrelevant. The claim that an actual system enforces these boundaries requires review and testing of that system.
This also separates context from agent memory. A specialist may retain task-specific working notes, while source records provide shared reference points. The Unified Context vs Agent Memory comparison explores that distinction in more detail.
Handle change before taking action
Suppose support reads a 14:00 appointment while a human receptionist moves it to 15:00. A later response based on the earlier record may be coherent but outdated. The design needs a rule for refreshing context before an action that depends on current state.
For this example, a rescheduling operation should check the appointment's current state in the system that owns it. If the operation fails, the agent should report the failure rather than recording a successful change in its summary. If a retry is possible, the workflow needs a way to avoid creating duplicate bookings.
These are concrete engineering questions for the consuming application. Context unification alone does not provide transaction control, concurrency guarantees or permission to change records.
Test the handoff with deliberate gaps
Start with one successful sales-to-scheduling handoff. Then repeat it with an unresolved identity, an inaccessible proposal, a stale appointment and an unavailable source. Examine whether the second agent sees the difference and whether the workflow avoids representing an incomplete operation as completed.
Ask the receiving agent to identify what remains unknown and what evidence supports the next step. Review the actual source responses alongside its answer. This evaluates continuity more directly than checking whether two agents produce similar prose.
For the interface layer, read Unified Context and MCP. Together, these articles separate connecting a capability, assembling context and completing a business operation.
Frequently asked questions
Do all agents receive the same context?
They do not need to. A useful design can preserve shared entity references while giving each agent information suited to its task and access rules. The important requirement is consistency about the relevant records, with missing or restricted information represented honestly rather than filled in by inference.
Is forwarding a transcript enough?
It may help a recipient understand the conversation, but it does not establish the current state of external records. In the booking example, the recipient also needs to know whether acceptance and scheduling actually occurred. A transcript, summary and confirmed source record have different evidentiary roles.
Does shared context guarantee correct actions?
No. Correct actions also depend on task instructions, permissions, tool behavior and current source state. This article describes how Unified Context can frame information continuity across agents. Actual correctness and isolation must be demonstrated by the implementation and the workflows that use it.