Ask an agent to follow up with a client, and it may find the last email you sent. Can it also find the pricing exception your colleague approved, the delivery date in the CRM, and the promise made in a team thread? That is the test for personal AI agents for work: whether the records available to one person are enough to speak for the company.
Key takeaways
- Test a work task against four requirements: source coverage, decision authority, access boundaries, and evidence before action.
- Access to a person's email or calendar does not establish access to the company's current decisions.
- An agent can retrieve the right document and still mistake a proposal for an approval.
- Shared company context can help an agent find relevant records. A person still needs to resolve conflicting sources and approve commitments when the task calls for it.
What is the four-part company context test?
The company context test checks whether an AI agent has the records, decision authority, access rights, and evidence needed for a specific work task. Run it before allowing an agent to answer a client, quote a price, or summarize a commitment. A failure calls for narrower output, more authorized context, or a human decision.
The four requirements are:
- Coverage: Can the agent reach the records that could change its answer?
- Authority: Can it distinguish an approved decision from a proposal?
- Access: Should the requester and intended recipient see this information?
- Evidence and action: Can someone check the claims before the agent sends, updates, or commits to anything?
This is a task-level test. An agent might have everything it needs to arrange a meeting and lack the records needed to confirm a contractual delivery date.
Why do personal AI agents for work need a company context test?
A person's accounts and a company's records have different boundaries. An inbox may contain a client's request without containing the team's latest decision about it. Connecting more personal accounts can improve coverage, but you still need to check which sources the task requires and whether the agent can use them appropriately.
| Work request | What a personal account might show | What else the answer may require |
|---|---|---|
| “Follow up with this client” | The user's last email and calendar meeting | Current account status and a delivery decision made by another team |
| “What price should I quote?” | An earlier quote or draft | Current rate card, account-specific exception, and approval owner |
| “What did we promise?” | A conversation the user joined | Signed agreement, later scope change, and the decision that governs now |
These are illustrative tasks. For each one, the question is whether the agent's accessible sources support the answer it proposes.
1. Does the agent have coverage of the records the task needs?
Coverage means reaching the records that could change the answer, including records held by another person or stored in another app.
Suppose a client emails an account manager asking whether a rollout is still on track. The manager's Gmail account has an older target date. Operations changed that date in Slack, and the account owner updated the opportunity in Salesforce. An agent working only from the manager's connected inbox may draft a clear reply with the wrong date.
How to test it: Before requesting a draft, list where a correct answer could live: the email thread, account record, and operations decision. Check which sources the agent can reach for this requester. If a required source is unavailable, supply it through an approved process or limit the output to a draft that flags the gap.
How it fails: A missing source leaves no trace in an answer based on the documents the agent did find. A longer prompt cannot reveal a decision in a Slack thread the agent cannot access.
For a meeting reminder, personal account coverage may be enough. For a statement about delivery, price, or contract terms, name the authoritative sources before drafting.
2. Can it tell an approved decision from a proposed one?
Finding a relevant message does not establish that its writer made the final decision. Work records contain suggestions, negotiations, superseded plans, and approvals in similar language.
Imagine an agent is asked, “Can we offer the client the same discount as last quarter?” An old quote gives one number. A current rate card gives another. A sales lead discussed an exception in Slack but asked finance to confirm it. Retrieving all three records still does not establish an approved price for this account and term.
How to test it: Require the agent to identify the current policy, any account-specific approval, who approved it, and its effective date. If the sources support only “proposed” or “pending,” the draft should leave the price open.
How it fails: An agent turns discussion into policy. “We could probably extend 15%” becomes a quote even though approval never arrived. Source citations let a reviewer inspect that message; the citation alone does not turn it into authorization.
Keep a human decision owner in the loop when records conflict or approval is unclear. The person requesting a draft may know the client well without having authority to set the price.
3. Is the context permitted for this person and task?
An accurate answer can still disclose information to the wrong audience. A company-wide policy, a team negotiation, and a private note should not have identical access boundaries.
Suppose an agent drafts a client update using a team discussion about how much the company is willing to concede. The discussion may help an internal reviewer understand the situation. Quoting it in the client-facing reply would expose information the client was never meant to receive.
How to test it: For a request such as “summarize what we promised this client,” list the likely sources. Mark who may read each one, then check whether the intended recipient may receive the resulting statement. Repeat the test when someone changes teams or leaves a project.
How it fails: A broadly connected account or pasted document gives the agent material outside the intended scope. Reviewing only the final send action misses information that may already have appeared in a draft shown to an unauthorized reader.
When evaluating a shared knowledge system, test its permissions with real roles and queries. Check both the retrieved material and the answer. A permission label matters only if those boundaries hold during the task.
4. Can a reviewer check the evidence before the agent acts?
A useful draft shows which sources support its material claims and where the records disagree. Sending the draft is a separate decision.
Return to the client follow-up. An internal draft might say, “The operations discussion gives October 14 as the revised target. The account record still shows October 10. Confirm the date before sending.” Those dates are an example, not a reported customer case. The unresolved conflict is exactly what the reviewer needs to see.
How to test it: Request a source for each material claim. Open the sources and check their dates, audience, and wording. Decide who may approve the client-facing statement and which actions the agent may take before that approval.
How it fails: A citation points to an outdated record, or the cited source supports a weaker claim than the draft makes. The agent may also have the correct facts and send before the account owner checks the commitment. Evidence makes review possible; it does not perform the review.
An AI tool can receive company information through a connector such as an MCP server if that tool supports the connection. Check the specific tool's current connection options and permission behavior before relying on it for a work task. Access to context does not itself authorize the tool to send email or change a record.
How do you audit a real task?
Start with a recent request that caused confusion, such as “What did we promise this client?” Map the sources and the approval decision before expanding the agent's access.
- Define the output. Specify the client, the commitment, and whether you need an internal summary or a client-facing reply.
- Name the likely records. Check the relevant email, CRM account, team discussion, and signed agreement. Include a record when it could change the answer.
- Identify the decision owner. Find who approved the commitment and whether a later decision superseded it.
- Check access. Confirm the requester may use each source and the recipient may receive the resulting information.
- Ask for a sourced draft. Open the cited records. If they conflict or approval is missing, keep the uncertainty in the draft.
- Set the action boundary. Decide who resolves conflicts and who sends or approves the final reply.
Run the same audit for a pricing request. You may find every relevant document and still lack a clear record of an approved exception. That is a decision to resolve, not a gap for the agent to fill by guessing.
Frequently asked questions
When is a personal agent's account access enough for work?
It can be enough when the task depends on records the user is authorized to access and cannot create an unapproved company commitment. Arranging a meeting from a connected calendar is one example. Confirming a price or delivery promise requires a check of shared records and decision authority.
What should an agent know before drafting a client follow-up?
It needs the client's latest request, current account status, relevant team decisions, and the approved commitment it plans to repeat. A reviewer should be able to inspect the supporting sources and confirm that the client may receive the information.
Does access to more apps solve the context problem?
More access can help an agent find relevant records. It does not establish which record is current, which proposal was approved, or whether the information may be shared with the intended recipient. Test those points against the specific task.
Do source citations make an agent's answer correct?
Citations let a reviewer check the record behind a claim. A cited record may be outdated, incomplete, or merely a proposal. Check that it supports the draft's wording and that no later decision changes the answer.
What changes when company context is available through MCP?
An MCP connection can give a compatible AI tool access to a company's selected information. The outcome still depends on what the company makes available, the applicable permissions, and how the tool uses the returned material. Confirm support in the specific tool before planning a workflow around it.
When should personal AI agents for work stop at a draft?
They should stop when a required source is missing, records conflict, approval is unclear, or sending would create a company commitment requiring a person to decide. A draft that identifies the unresolved question is more useful than a confident answer built on a guess.
If your audit finds that an agent lacks shared company context, start building your company brain with Gyld. Choose the information you want your AI tools to work from, then test it against a real task.