Every time you use AI, you have to tell it what to do.
You explain the assignment. You reintroduce your role. You paste in the background. You remind it how your manager wants the answer structured and what “good” looks like. When the first response misses something important, you correct it and try again.
Then the AI does something useful.
It summarizes the meeting. Drafts the update. Organizes the research. Gives you a starting point.
That is the behavior of a helpful tool. It waits for a request and works from the context available in that moment.
A Work Partner should carry more of the relationship. It should understand the part of your job it supports, the people who use your work, the standards you apply, the decisions you can make, and what has changed since the last assignment.
Right now, the burden of continuity sits with you.
*Give it the task.*
*Load the background.*
*Correct the assumptions.*
*Do it again next time.*
Most employees are operating a capable tool one request at a time. The partner layer remains to be built.
If this is your workflow, you can still get good output. Reliability remains fragile because the understanding lives with you. The system receives whatever portion you manage to provide in that conversation.
This article is about moving that understanding into a maintained professional context base. That base helps the AI recognize your role, standards, current operating situation, and judgment boundaries before you assign the next responsibility.
Your AI needs a maintained picture of your work
Context engineering is the ongoing work of selecting, organizing, delivering, and maintaining the information an AI system needs for the task in front of it.
For an employee, that information includes more than company documents. The system also needs a maintained picture of the employee’s role, how the work creates value, which audiences receive it, how judgment is applied, and what is happening right now.
I call that a professional context base.
I am using the phrase as an ordinary description. The useful structure may vary by role. A context base contains the background you repeatedly explain and the operating information your Work Partner repeatedly needs.
Capture the context that changes slowly
Some parts of your work remain useful across many assignments:
Your role and the contribution you are expected to make
The responsibilities you carry and the decisions you support
The people who use your work and what each audience needs
Your communication preferences and accepted output formats
Examples of work that met the standard
The principles you use when evidence is incomplete
Professional boundaries and information you keep out of the system
The direction you want your contribution to move
For a Program Manager, for example, this might include a short explanation of her role in program decisions, a stakeholder map, examples of accepted updates, rules for labeling proposals, and a note on how leaders want issues presented.
Much of this can live in a small set of maintained documents. The format matters less than the discipline. Someone can read the material, correct it, identify its owner, and replace it when the work changes.
The personal boundary deserves care. A company AI tool rarely needs your private life story. Professional values, judgment principles, and working preferences may be relevant. Medical information, family details, political views, private aspirations, and other sensitive material deserve a much higher threshold before they enter an employer-managed system.
Useful context earns its place by helping with approved work.
Capture the context that changes with the week
The second kind of context moves faster:
Current priorities
Active projects and milestones
Recent decisions and open questions
Commitments, owners, and dates
Risks and dependencies
Changes in stakeholders or decision rights
Temporary constraints
The next outcome the employee is trying to produce
This is where an AI setup quietly goes stale.
The role description may still be accurate while the program priority changed last Thursday. The accepted update format may still be useful while the decision record contains a new owner. The Work Partner can retrieve an authentic source and still produce the wrong answer for today.
Give changing context an owner and a review rhythm. A current program brief may need a weekly check. A role description may deserve review when the job changes. An example can expire when leadership changes the format.
Put the review date next to the context so its currency stays visible.
Turn conversation into a context asset
Many employees have not written this material down because they learned it through work. They know that the finance leader wants the risk before the recommendation. They know which meeting notes count as decisions. They know that “final” means three different things across three systems.
The knowledge is real. It is also tacit.
A guided AI conversation can help extract it. Ask the system to interview you about one topic at a time. Two or three questions are enough for a pass. Let it reflect what it heard, correct the weak parts, and compile the result in your language.
For example:
Ask me three questions about my role in this program, the decisions I support, and the decisions that stay with other people. Reflect my answers before drafting a one-page role brief. Use my language. Mark anything you inferred so I can correct it.
Then repeat the process for communication standards, current operating context, judgment boundaries, and goals for the responsibility area.
The result should become a maintained source, rather than another useful exchange buried in chat history.
Chat history can help a model recognize patterns. Its contents may also mix old priorities, abandoned ideas, private conversations, and corrections that were not promoted into a current source. A reviewed document gives the employee something concrete to inspect and update.
Select the context for one part of your job
A broad professional context base can support several kinds of work. A specific Work Partner should receive the parts relevant to its assigned responsibilities.
The useful scope is often a coherent responsibility area. Three to five recurring responsibilities can belong together when they use many of the same sources, serve related stakeholders, and contribute to the same outcome.
For the Program Manager, that area could be program coordination:
Prepare a daily program brief
Assemble meeting context
Draft a decision brief
Prepare meeting follow-up
Draft the weekly program update
Each responsibility draws from the shared professional context base. Each also needs its own working information.
The daily brief needs current milestones, commitments, and risks. The decision brief needs decision rights, alternatives, evidence, and the question requiring resolution. The weekly update needs the accepted format, current plan, completed work, and leadership audience.
The employee maintains the background once and chooses the relevant parts for the work at hand.
Context gives background; procedures give the Work Partner a job
A professional context base can make an AI response more specific to the employee. Each responsibility requires its own operating details.
Each responsibility still needs:
A trigger that starts the work
Approved inputs
A procedure, including common exceptions
The expected output and audience
Examples of acceptable work
A quality standard
Permission boundaries
Stop conditions
A test case
Imagine the Work Partner preparing the weekly program update. It needs to know that the Program Manager supports the decision and does not make it. It also needs a procedure for comparing the current plan with the prior update, preserving approval status, listing commitments by owner and date, and surfacing conflicts for review.
Personalization shapes how the system interprets the work. Job design tells it how to perform the responsibility.
That is the point where an AI tool begins to resemble a Work Partner.
Keep company authority separate from technical access
A connected source is technically available. Company policy determines whether the system may use it for this purpose.
The same boundary applies to action. A Work Partner that drafts an email and a Work Partner that sends it carry different exposure.
For each responsibility, record what the Work Partner may research, draft, recommend, prepare for approval, or execute through an approved company process.
People decisions, payments, legal obligations, compliance, security, customer commitments, and external communication deserve a visible human checkpoint unless the organization has approved another control.
“Stop and ask” remains a useful capability. It belongs next to the context because the Work Partner needs to recognize the situations that exceed its role.
Test whether the context actually works
A polished answer cannot tell you whether the context base is dependable.
Test four different things:
Access: Was the current source available?
Retrieval: Did the system find the relevant information?
Application: Did it apply the information according to the procedure and boundaries?
Evaluation: Could a person judge the result against a written standard?
Start with work you already understand and are permitted to use. Include a known answer, missing information, conflicting sources, an out-of-scope request, and an awkward exception.
Then test the context itself. Ask the Work Partner to explain your role in the responsibility area. Ask which source has authority. Ask what changed recently. Ask it to show which part of the context shaped a recommendation.
The test may reveal that the document is missing information. It may reveal a retrieval problem. It may reveal that the decision rule remained tacit.
All three are useful findings.
Give your manager a view of the arrangement
The manager needs enough visibility to evaluate the work design while the employee keeps unrelated personal notes outside the view.
A one-page manager view can include:
The responsibility area the Work Partner supports
The professional and company context it uses
Information deliberately excluded
The outputs it prepares
The employee’s review responsibility
Actions requiring approval
Known limitations and test results
The owner and review rhythm for changing context
The employee could open the conversation this way:
I have built a professional context base for my program-coordination work and configured an AI Work Partner around five recurring responsibilities. It uses these approved sources. I review every output before it is shared. Here are the boundaries, tests, and context that needs regular updating.
That gives the manager a specific arrangement to review.
Start with the explanation you are tired of repeating
You can try this with one piece of context today.
Write down the explanation you keep giving your AI. Perhaps it is your role in a decision, the way your manager wants updates, the difference between a proposal and a commitment, or the current priorities shaping your work.
Turn that explanation into a reviewed source. Add its owner and review date. Use it in one recurring responsibility. Test whether the system retrieves and applies it.
Then decide what deserves to become part of the maintained context base.
An AI Work Partner grows from two kinds of clarity: a current picture of the employee’s work and a bounded description of the responsibilities the system supports.
If you keep explaining your role, priorities, and standards every time you open AI, subscribe to my Substack and get the revised My AI Work Partner Builder. It will help you capture your professional context, configure one responsibility area, and show your manager how the arrangement works.