KanBo Perspective

The Assistant’s Assistant

The person who manages an executive’s attention is about to become the person who manages an agent’s output. It is the first role in the enterprise where AI genuinely works — and a preview of what most knowledge work is about to feel like.

The role everyone misreads

Almost everything written for Executive Assistants is about calendars. Almost nothing an experienced EA does is about calendars.

The actual product of the role is control over a senior executive’s attention. What reaches them and what does not. What they asked for three weeks ago and whether it arrived. What they promised in a meeting and whether anyone is delivering it. Which of the two hundred things happening across the organization are the four they need to know about today.

Herbert Simon put the underlying economics in a sentence in 1971: a wealth of information creates a poverty of attention. Every organization has been getting richer in information ever since. The role that manages the resulting poverty has been treated as administrative support.

There is a structural weakness in how the job is currently done, and it has nothing to do with the calibre of the people doing it. The executive’s open commitments live in one person’s inbox, notebook and memory. That means every question is a retrieval task, every absence is a risk, and the assistant becomes both the organization’s routing layer and its single point of failure. The better they are at it, the more completely the organization depends on them being at their desk.

First, the work itself — no AI required

Before any of the AI argument is worth making, it is worth describing what this job looks like when the executive’s commitments are held in a shared record rather than in one person’s head. Everything that follows in this article is an extension of this. Skip it and the agent sounds like a leap; read it and the agent is the obvious next step.

The description below is of KanBo, which is the work coordination platform we build, adopted at organization level with access and deployment governed centrally. An EA working this way uses it directly, through the interface, in a handful of habits.

Commitments become items. Every request that comes out of the executive’s meetings becomes a card — a work item — with a named Responsible Person and a real date, in a space, which is the permissioned container a programme or an office runs in. The line “Finance will get us the revised numbers before the board” stops being a note in the EA’s pad and becomes something with an owner that other people can see.

Requests arrive as work rather than as messages. A space can be given its own email address, so a request forwarded from Outlook lands as a structured item with an owner and a due date. Nothing is retyped, and the request no longer lives only in the EA’s inbox.

One personal view across everything. The EA’s own space gathers the items they own or watch from every space in the organization. They filter it for what is overdue, what is blocked, and what falls before the executive’s next meeting. This is the replacement for scanning an inbox and hoping nothing was missed.

Dependencies and obstacles are recorded, not remembered. Items link to each other across departments, so a commitment owned by procurement can be visibly the thing a board deadline waits on. An obstacle is a named object with a reason and a responsible owner, which turns “we’re still waiting on Legal” from a recurring complaint into a fact with a person attached.

Documents are connected, not copied. Files reach items through managed connections to the repositories the organization already uses, so the board pack on the item is the board pack in the library rather than a version that started diverging when it was attached.

Confidential work is genuinely separate. A restructuring, an executive search or a transaction runs in a private, closed space, with access granted through six permission levels. It is not hidden by convention; it is invisible to anyone outside it.

Recurring events run from templates. Board meetings, offsites, executive onboarding and reporting cycles are set up once as templates carrying their own items, dates and document structure. The eightieth quarter is as complete as the first.

And the executive is given access rather than a report. Instead of a compiled summary, the EA curates a space for them using mirror cards: a mirror card surfaces the live item itself in another space rather than a copy, so there is one truth and many views, and an update by the owner is an update in what the executive sees. Dates can flow into their Outlook as tasks, as appointments, or not at all.

And the EA’s reach is not limited to the executive’s own items. Within the permissions they hold, the assistant can see the live state of the programmes the executive sponsors — not a report about them, the work itself. That changes the first move when something is needed. The question is answered by looking, before anybody is asked anything.

That habit has a name worth using, because it is the discipline that makes the whole method work: increasing engagement.

Every way of getting an answer costs somebody’s attention, and they are not equally expensive. Reading a card costs nobody anything. Reading its history and documents costs nobody anything. Leaving a comment or mentioning the owner costs them a little, at a time of their choosing. A direct message costs more. A call on Teams interrupts them outright. Convening a meeting takes an hour from everyone in it.

The rule is to answer at the lowest level that actually works, and to escalate only when the record is genuinely insufficient — and then to escalate deliberately, to the one person who can close the gap, with a question sharpened by everything already read.

Most organizations operate the other way around, and not through carelessness. They start near the expensive end because the cheap end holds nothing: there is no record to read, so the first move is always to ask a human. An enormous amount of what an organization experiences as being busy is simply coordination conducted at an unnecessarily high level of engagement.

That is the whole method, and it works with no AI involved at all. The EA reads, filters, curates and decides — by eye, through the interface. It is already a substantial improvement on an inbox and a spreadsheet, because the executive’s commitments now exist outside one person’s memory, and because holidays and handovers stop being events the executive suite braces for.

But notice what the EA is still doing in that picture: sweeping. Opening views, applying filters, scanning eleven programmes for what changed, assembling the position by reading. It is faster and far more reliable than messaging colleagues, and it is still a person’s eyes moving across a structured record, every morning.

This is the point at which an agent stops being a leap and becomes an obvious next step. It reads exactly the same record, through a different door — MCP rather than the interface — with exactly the same permissions the assistant holds. It is not a new source of knowledge and it learns nothing the EA could not have found by looking. It is a second reader of the same truth, working considerably faster than eyes.

In the terms above, the agent lives entirely on the cheapest rung. Connected to KanBo over MCP, it reads everything the assistant is entitled to read — cards, statuses, dates, dependencies, blockers, activity history — across every space at once, and interrupts nobody in doing it. Which leaves the assistant’s escalations for the cases that genuinely need a person — and makes those escalations better, because by the time anyone is called, everything knowable from the record is already known.

Why the “AI will replace assistants” argument gets it backwards

The prediction is common and it is wrong, but not for the comforting reasons usually given.

It is not wrong because AI is bad at this. An agent is genuinely excellent at the parts of the job that involve gathering, cross-referencing and drafting. Anyone claiming otherwise has not tried it recently.

It is wrong because those are not the parts that make an EA valuable. The value is in weighing: knowing that one overdue item is harmless and another, entirely unflagged, will detonate at Thursday’s board meeting. Knowing that this request should go to the executive and that one should be answered without troubling them. Knowing which colleague responds to a direct ask and which needs to be given room. None of that is written anywhere, and most of it is about people rather than tasks.

So the real prediction is close to the opposite. The EA is one of the few roles where an agent can be deployed usefully today — because the person supervising it already has decades of institutional practice at exactly that supervision. Briefing a fast, capable, contextless helper and checking its work is not a new skill for an assistant. It is the skill.

What changes is the ratio. The collection half of the job, which has always consumed the day, compresses to minutes. The judgement half, which never had enough time, expands to fill the rest.

The condition nobody mentions

There is a condition, and it is the whole game.

An agent can only reason about what is written down. Ask it what is at risk before the board meeting and it needs to know what exists, who owns it, what state it is in, what it depends on and what is blocking it. In most organizations none of that is recorded anywhere a machine can read. It is in email, in chat, in a spreadsheet, and in the EA’s head.

This is why so many assistant pilots stall in exactly this territory. The model is not the limitation. It is being asked to reason about a state of work that was never captured. What comes back is fluent, confident and unverifiable — which in an executive context is worse than nothing, because checking it costs more than doing the work by hand.

The fix is not a better model. It is a record: commitments as items with named owners, real dates, dependencies expressed as links between departments, and obstacles named with someone responsible for them. That is what the working method described above produces — in KanBo, cards carrying their own owner, status, dates and history, linked to each other across spaces — and it is the precondition for everything that follows.

Sequence matters here, and most organizations attempt it backwards. Write the state down first. Introduce the agent second.

Building the agent is now the easy part

It is worth being blunt about where the difficulty actually sits in September 2026, because a great deal of enterprise effort is currently going into the wrong half of the problem.

Building an assistant is no longer hard. Wiring a capable model to a set of tools, giving it instructions and putting a chat box in front of it is an afternoon’s work with widely available components. It has roughly the difficulty of writing a formula into a spreadsheet cell. That is not a criticism of anyone doing it — it is a statement about how far the commodity layer has moved. Model capability is no longer the constraint on enterprise AI, and treating it as though it were is why so many programmes are stalled.

The scarcity has moved to three places, none of which is the model.

Whether the system holds state or prose. An agent pointed at documents and message threads can summarise. An agent pointed at a record of work — owners, statuses, dates, dependencies, blockers — can answer operational questions. These are different activities and they are routinely confused. If your systems only hold prose, no model will turn them into answers; it will turn them into confident paraphrase.

Whether the system has an identity model that survives a machine consumer. This is the one almost nobody plans for, and it is where most pilots quietly die. Ask what access an agent will have in your existing systems and the honest answer is usually: it gets a service account, and that account has broad rights, because service accounts were designed for overnight batch jobs rather than for something that reasons and acts on a person’s behalf. Bolting an agent onto a system with one all-powerful integration account is not an AI project. It is a privilege-escalation project with a chat interface, and the security function will eventually say so.

Whether actions remain attributable to a person. If the agent writes back and the audit trail records “API user,” the record has stopped being evidence. Everything downstream — audit, dispute, regulatory response — degrades from that point.

The underlying problem is simple to state. Most enterprise systems were designed on the assumption that only humans would ever read them, and only humans would ever act in them. Everything about their interfaces, their permissions and their logging follows from that assumption, and none of it survives the arrival of a competent machine consumer.

This is where the KanBo arrangement differs, and it is worth stating precisely because it is the part that makes the earlier sections deployable rather than aspirational. An agent connecting over MCP authenticates through delegated authorization — OAuth — as the person on whose behalf it is working. It is not a superuser with a token. It signs in as the assistant and inherits exactly the assistant’s permissions: the same six permission levels, the same group memberships, the same private spaces open and the same ones closed. If the EA cannot see the acquisition space, neither can their agent.

That single design decision resolves most of the objections an enterprise raises. Access is not a policy the agent has been asked to honour; it is a boundary it cannot cross. And when the agent acts, it acts as a delegated identity with a person behind it rather than as an anonymous integration.

The uncomfortable conclusion for anyone evaluating this: the interesting question is no longer “can we build an agent.” Everyone can build an agent. The question is whether the systems you would point it at were built on the assumption that something other than a human would one day read them. Most were not.

What the EA can make an agent do

The honest answer to “what can the agent do” is: whatever the assistant describes to it.

That sentence is doing more work than it appears to. It means the capability boundary of this arrangement is not set by a vendor’s roadmap, a release cycle or a development team’s backlog. It is set by the person who actually understands the executive’s world — and set by them directly, in their own words, on the day they need it.

How that works in practice. The organization approves the AI environment once and connects it to KanBo’s MCP server once: identity, permissions, deployment, the usual governance. That is IT’s job and it happens a single time. After that, the configuration is the assistant’s own. They write instructions in plain language describing what they want prepared and how. They save the ones that work as reusable skill files, so “prepare the Thursday board sweep” or “build the pre-meeting pack for a supplier review” becomes something they invoke rather than re-explain. They connect the tools they are permitted to use, and adjust the phrasing when the output is not quite right.

None of that requires a developer. There is no ticket, no scoping conversation, no queue, no six-week wait for something that arrives slightly wrong because the person who built it had never sat outside a chief executive’s office.

Why this is the substantial change. For thirty years, the gap between “I know exactly what I need” and “I have it” has been an organizational process. The person with the domain knowledge wrote a requirement; somebody without that knowledge implemented it; the difference between the two was absorbed as frustration. Here the person with the knowledge is also the person who configures it, and the loop between noticing a need and satisfying it closes in minutes.

This is genuine end-user programming, and it deserves to be recognised as such — including its obligations. Instructions that work should be kept and versioned rather than retyped from memory. New ones should be checked against a case where you already know the answer. Output should be reviewed periodically for drift, because a set of instructions that was right in March may quietly stop being right in September.

And the boundary that makes it safe. Freedom to configure behaviour is not freedom to expand access. However the assistant instructs their agent, it still runs under a delegated identity with exactly the assistant’s permissions. It can be told to do something new; it cannot be told to see something new. That separation — behaviour open, access closed — is what allows this to be handed to a non-technical person in a regulated organization without anyone losing sleep.

What assistants tend to build first. The pattern is consistent enough to be worth listing, as examples rather than as a menu:

The morning sweep. What changed since Friday across these eleven programmes. What is blocked and on whom. What is due before Thursday. What is still waiting on him. Which of last month’s commitments has gone quiet.

The pre-meeting pack. For a given meeting: everything open with the people in it, everything the executive owes them, everything they owe the executive, what was decided last time.

Cross-programme pattern-finding. Which obstacle recurs across unrelated initiatives. Which department appears as a blocker most often. Which commitments made in January have neither moved nor been cancelled.

Drafting. The update, the chase, the summary, the agenda — drafted, not sent.

Watching. Flagging when something the executive is exposed to changes state, rather than waiting for the weekly cycle to surface it.

Every one of those is collection, correlation or composition. That is where current models are strong and where the work was always mechanical.

What an agent cannot do

The list is shorter and more important.

Weighing. Deciding what deserves attention is not a ranking problem with a hidden correct answer. It depends on what the executive is preoccupied with this week, which board member asked the question, and whether the person who is late has been reliable for ten years or is new and struggling.

Discretion. Knowing what not to send is at least as valuable as knowing what to send, and an agent optimising for completeness will get this exactly wrong. The instinct to withhold something until Monday because raising it on Friday afternoon achieves nothing is not inferable from the record.

Reading the room. Whether the delay is a resourcing problem or a political one. Whether the polite update means it is on track or means the opposite. Whether a chase will produce the document or produce resentment.

Owning the outcome. Someone has to be accountable, and it has to be a person. This is not a philosophical preference; it is what makes the arrangement acceptable to a board, an auditor and a works council.

The line: proposes, decides, confirms

Stated as plainly as possible, because this is the part that determines whether the arrangement survives contact with a real organization.

The agent proposes. It reads, correlates and drafts. It produces candidate answers, candidate priorities, candidate messages.

The human decides. The EA reviews what came back, applies the judgement above, and determines what reaches the executive. Nothing goes up that the EA has not chosen to send.

A human confirms any action. When work flows the other way — an agent creating follow-up items, updating a status, sending an update — a person confirms it before it happens. And the Responsible Person, which is a field on every KanBo card rather than a convention, remains a named human being.

That last point is not a detail. If accountability can be assigned to an agent, the record stops being usable as evidence and the whole structure fails its first audit. Keeping the named human on the item is what makes agent involvement deployable in a regulated organization rather than merely impressive in a demonstration.

What to delegate, and what never to

A practical division, worth agreeing explicitly rather than discovering by accident.

Delegate to the agent: gathering status across programmes; identifying what changed; finding what is blocked and by whom; cross-referencing commitments against dates; assembling pre-meeting context; drafting routine updates, chases and agendas; noticing that something has not moved.

Keep with the human: deciding what reaches the executive; deciding what to withhold and when; anything involving a person’s performance or standing; anything confidential by category rather than by content — personnel matters, transactions, executive search; the final wording of anything that carries the executive’s voice; and every decision about priority.

Never delegate: accountability. The agent is an instrument the EA uses. It does not become the responsible party for anything, and the record should never suggest it did.

The deliverable changes shape

Here is the second-order change, and the one most organizations will resist longest.

The daily brief, the status email and the Monday catch-up all share a flaw: they are snapshots. Accurate at the moment of writing, degrading from then on, and impossible to interrogate. Every follow-up question routes back through the assistant — which is exactly the bottleneck the brief was supposed to relieve. The executive asks “and what about the Riyadh contract?”, and the EA goes back to the source.

When the commitments live in a shared record, the brief can change shape entirely. What reaches the executive is a short note on what needs them, alongside curated direct access to the actual items, mirrored into a space of their own — the live items themselves, not copies. Opening one shows the owner, the dates, the dependency holding it up, the document under discussion and the reasoning that produced the current position.

A summary answers the first question and creates the next three. Direct access answers all four.

This is a genuine break in habit and should be treated as one. Executives who have been briefed the same way for twenty years do not switch because a vendor suggests it. The practical route is to replace one artefact — the weekly status email, or the first fifteen minutes of the standing catch-up — and let the comparison make the argument.

Drucker’s point in The Effective Executive is the underlying reason to bother. Time, he argued, is the one genuinely scarce and non-substitutable resource, and effective executives begin by finding out where it actually goes rather than where they assume it goes. That is not possible when the only instrument is a document written by somebody else, yesterday.

What an agent is allowed to see

Any serious version of this raises a governance question before it raises an enthusiasm question, and rightly. An executive’s environment contains the most sensitive material in the organization.

The answer has to be structural rather than a policy commitment. In KanBo, an agent connecting over MCP acts under an identity, and that identity is governed by the same permission model that governs people: six levels, grantable to groups, deny by default. A service identity that has not been mapped to a user holds no permissions at all until a role grants them.

The practical consequence is that confidentiality is enforced by the same mechanism for machines as for people. A private, closed space containing a restructuring, an acquisition or an executive search is invisible to an agent that has not been admitted to it — not because the agent has been instructed to avoid it, but because it cannot see it exists.

That distinction matters more than it might appear. “The assistant has been told not to look at that” is a control that fails silently. “The assistant cannot see it” is a control that fails loudly, which is the only kind worth having.

Three situations, before and after

The executive asks about something from six weeks ago

Before. The EA remembers the conversation, is fairly sure it went to the operations director, and messages two people to find out where it landed. An answer arrives that afternoon.

After. The commitment is a card with a named Responsible Person and a date. Its activity history shows what has happened since, what it is currently waiting on, and who last touched it. It takes seconds, and the EA did not interrupt anyone to produce it.

Preparing for a board meeting

Before. Two days of collecting inputs from programme leads, chasing the ones who are late, assembling a pack, and discovering on the morning that one number changed.

After. The agent assembles the current position across every relevant programme, flags what changed in the last week and what remains unresolved. The EA reviews it, decides what the board actually needs, and prepares that. The pack is built from live items rather than from fourteen emailed contributions.

The EA takes a week’s holiday

Before. The executive suite braces. Requests queue, context is unavailable, and something usually slips. The EA answers messages from the airport.

After. Commitments, owners, dates and history are on the work rather than in one person’s memory. A colleague covering for the week can see the position rather than inherit a mystery. This is the change that matters most to the organization, and the one least often discussed with the person it most benefits.

The EA as a preview of everyone else’s job

Step back and this stops being an article about assistants.

Within a few years most knowledge workers will supervise agents. The pattern will look remarkably like what an EA already does: brief a fast, capable helper that has no context of its own, check what comes back, decide what matters, and take responsibility for the result.

Executive Assistants have been practising this for a century — with junior staff, with agencies, with vendors, with an entire organization they have no authority over. They are unusually well-prepared for the transition, and they will hit its problems first.

Which makes the role worth watching for reasons beyond itself. The questions being answered at this desk right now — what to delegate, how to verify, where accountability sits, what an agent may see, what a person must decide — are the questions every function will be answering shortly. The EA’s version simply has the shortest feedback loop and the least tolerance for error.

Honest limits

The record has to be real. Everything here depends on commitments actually being captured as cards with named owners and dates, in spaces the relevant people genuinely work in. Where teams do not work that way, the agent has nothing to read, and it will produce confident output from a partial record — which is more dangerous than an empty one.

Skills decay when you stop using them. Lisanne Bainbridge described this in 1983 as the irony of automation: automating the routine parts of a task leaves the human with only the difficult parts, while removing the daily practice that kept them sharp at those parts. An EA who never again sweeps manually may become slower at noticing what the sweep missed. The countermeasure is not to refuse the tool; it is to keep reviewing the raw record periodically rather than only the agent’s summary of it.

Over-trust arrives quickly. The output reads as authoritative. After a month of it being right, it stops being checked properly. Build in a habit of verifying against the record on a schedule, not only when something feels off.

Some executives will not change. A number of them want a document at seven in the morning and will continue to want one. That is a legitimate preference, and the agent still saves most of the time — the brief is now drafted from the record rather than assembled from colleagues.

Confidentiality has edges. Not everything sensitive is neatly contained in a private space. Before the agent is given broad access, someone should walk the actual permission boundaries rather than assume them, and in jurisdictions with works council involvement that conversation belongs at the start rather than after the first report exists.

How to start

One executive, one quarter, three steps.

Capture the commitments. Every request that comes out of the executive’s meetings becomes a KanBo card with a named Responsible Person and a date, in a space for that programme or for the executive’s office. Nothing else changes yet. This alone will surface how much was previously held in one person’s memory.

Add the agent, read-only at first. Let it do the morning sweep and pre-meeting preparation. Keep everything it produces as a draft the EA reviews. Spend a few weeks simply comparing its output against what you already knew — that is how you learn where it is strong and where it needs correcting.

Replace one artefact. The weekly status email, or the first fifteen minutes of the standing catch-up. Substitute a short note on what needs the executive, plus direct access to the items themselves.

Then apply the only test that matters: how often does anyone still have to ask the EA where something stands?

FAQ

Is this just a chatbot with access to a task list?

No. A chatbot answers from general knowledge or from documents. This is an agent reading the organization’s live record of work — current owners, statuses, dates, dependencies and blockers across every space it is permitted to see — and it acts under an identity whose permissions the organization controls.

We already have Copilot. Isn’t this the same thing?

They answer different questions, and they work well together. Copilot reasons over documents, email and conversations — it is excellent at “summarise this thread,” “draft this note,” “what did that report say.” It is reasoning over prose. An agent connected to the work record reasons over state: who owns this, what is it waiting on, what is blocked, what changed since Friday, what is at risk before Thursday. Ask Copilot an operational question and it will summarise what people wrote about the work; ask it of the record and you get the position of the work itself.

The two are complementary rather than competing, and in a Microsoft environment they sit side by side in practice: requests forward from Outlook into a space and become items with owners and dates, KanBo dates flow back into Outlook as tasks or appointments, work is discussed in Teams, and group membership comes from Active Directory. The record is the missing input, not a replacement for the assistant you already have.

Do we need developers to build the agent?

No, and that is much of the point. The organization approves and connects the AI environment once — identity, permissions, deployment. From there the assistant configures the agent themselves in plain language, keeps the instruction sets that work as reusable skills, and adjusts them as needs change. The capability is defined by the person who understands the job rather than by a development queue. What they cannot change is what the agent is allowed to see: behaviour is open to configuration, access is not.

Does the executive have to learn a new system?

No, and the design assumes they will not. The executive maintains nothing. They receive a short note and, when they want detail, open the item itself. Dates can flow into their Outlook as tasks or appointments. The curation is the EA’s work.

What happens to the EA role?

The collection half compresses; the judgement half expands. In organizations that do this well, the number of assistants does not fall — their scope rises, because the constraint was never headcount, it was hours spent on retrieval.

Who is accountable when the agent gets something wrong?

The person who sent it. That is the point of keeping a human in the loop and keeping a named Responsible Person on every item. An arrangement where accountability can be attributed to an agent is one that will not survive its first serious incident.

Can we restrict what the agent sees?

Yes, by the same mechanism that restricts people. Six permission levels, grantable to groups, deny by default, and a service identity with no permissions until a role grants them. A private closed space is invisible to an agent that has not been admitted to it.

Where does the record actually live?

KanBo is adopted at organization level, with access governance and deployment decided centrally — including on-premises and hybrid arrangements. For a dataset that contains an executive’s commitments and the organization’s internal friction, where it resides is a constraint rather than a preference.

Written by KanBo. We build the work coordination platform described here, so this is an argument we have an interest in. The condition in the third section — that an agent can only reason about what is written down — is worth testing against whatever you already have, including us.