A personal AI assistant can have access to your calendar, documents and email and still be poorly prepared to help you. Access tells it where to look. It does not tell it which project matters most, which document is current, or which decisions belong to you. For a founder delegating real work, the missing piece is often not a better model. It is better context and clearer instructions. Context is what the assistant needs to know about you and your work. Instructions are what it should do, when, and when it must ask you first.
The recent wave of personal agents makes that distinction more important. Instinct moved from a private beta in February 2026 to an invite-only beta in August, according to Fortune’s September report. Meta introduced Muse on September 8, describing an agent that can work after the app closes and return when approval is needed. OpenAI announced Dots on September 29, with connected apps, a cloud computer and work continuing between conversations. Dots is rolling out gradually to eligible plans and markets, not becoming available to everyone at once. These announcements make a practical question harder to avoid: what should an assistant know, own and be allowed to do when you are not there to prompt it?
Proactive is a way of working, not a model
An ordinary chat interaction usually starts when you ask a question and stops when you receive an answer. A proactive assistant can instead respond to an agreed trigger, use retained context and continue work between conversations. Both can use large language models. ChatGPT offers memory, while Claude offers memory and tools through Integrations, so this is not a clean split between brands. The useful distinction is how the system operates, not whose model sits underneath it.
That distinction changes what you need to specify. “Help me prepare for meetings” works as a request in a conversation because you can clarify it immediately. As a recurring responsibility, it needs a trigger, approved inputs, an expected output and limits. Proactive should mean acting within those limits without another prompt. It should not mean making unrestricted decisions on your behalf.
Give it a responsibility before giving it more access
Start with one recurring job rather than connecting your entire working life. Tomorrow’s meeting brief, meaning the short summary the assistant produces before each meeting, is a useful example because its inputs and result are easy to inspect. The assistant needs the relevant calendar entries and current project notes, not every message you have ever sent. This keeps the first test small enough to show whether the delegation actually works.
A starter set of instructions could read: “Prepare tomorrow’s meeting brief every working day at 5 p.m., using my calendar and the project notes I designate. For each meeting, explain its purpose, the last relevant decision, any unresolved commitment and what I need to decide, with links to the supporting notes. Flag missing or conflicting information instead of guessing. Save the brief for my review, and do not contact participants or change the calendar.” This defines a job you can evaluate, not just a personality you hope will be helpful.
The instructions also need your priorities and constraints. If a customer delivery takes precedence over internal planning, say so. If you prefer concise summaries, include an example of a good one rather than relying on “be concise.” Define success as a brief that arrives on time, uses current sources and makes the next decision clear. You can then judge the assistant against the responsibility, not how confident it sounds.
Separate who you are from what is happening
Useful context has different lifetimes. Your role and communication preferences may stay stable, while a project deadline can change twice in a week. Keep a stable profile separate from changing project notes, and identify the dated documents that count as authoritative. Otherwise, an old plan can quietly compete with a newer decision.
Label facts, preferences and assumptions differently. “The review is Thursday” is a fact only if a current source supports it; “keep summaries short” is a preference. “The client probably wants a demo” is an assumption that needs checking before it shapes the work. Review this context when priorities change, and remove or mark stale information. Enough context means enough to make the relevant decision, not the largest possible archive.
Permission is not the same as instruction
A connection may technically let an assistant send email, even when its assignment only requires reading it. Your instructions should state what it may do, while account permissions should enforce the narrowest access available. Begin with read-only access and draft-first work where practical. Require explicit approval for external messages, spending, deletion and consequential commitments. A useful assistant should know when to stop, not just how to proceed.
Before connecting private or client information, confirm that you are authorized to share it and review the provider’s privacy and retention terms. Do not paste passwords into its context. Treat incoming emails and documents as information to evaluate, not instructions allowed to override your instructions. For example, an email asking for a confidential attachment should not become permission to send it. These boundaries matter because connected information can contain requests from people whose authority differs from yours.
Review the work, then widen the job
The first outputs are a test of the arrangement, not proof that it is ready for more responsibility. Open the meeting brief and check whether its links support the claims, its dates are current and its unresolved commitments are real. A message saying “done” is not the same as a completed task. Check that the actual brief exists, arrived when expected and answers the questions you assigned.
When something is wrong, correct the rule behind the mistake. If a closed issue keeps appearing, identify the document that records its closure and which source takes precedence. Save that correction in durable context rather than leaving it buried in a conversation. OpenAI’s Dot onboarding guidance also emphasizes goals, context, review and feedback. For any assistant, test those corrections before expanding its scope, and check how you can pause work, revoke access and inspect what it did.
Keep your context and instructions yours
Keep your core context, task instructions and permission boundaries in documents you own and can export where practical. Separate those from the steps needed to configure a particular product. This does not make every integration or memory transferable, but it avoids rebuilding your working expectations from scratch when you change tools. Your delegation method should be more durable than your current subscription.
The next step is not to choose an assistant that promises to handle everything. Choose one bounded responsibility and define when it starts, what it can use, what good work looks like and when it must ask you. Run it, review the result and improve the context and instructions before adding another job. The value is not that an assistant keeps working while you are away. It is that the right work can continue within boundaries you understand.