---
title: "The Personal Assistant Is the Next Interface"
description: "Putting inference in a chat window was the first interface revolution. The second is one assistant in front of all those conversations: it decides which session, agent, or machine does the work, keeps the context, and comes back with the outcome. OpenAI's dots and Instinct show two versions of it, and why every frontier lab will need one."
date: 2026-10-27T00:00:00.000Z
author: "Kobi Kadosh"
url: https://kobi.kadosh.me/blog/2026-10-27-the-personal-assistant-is-the-next-interface
category: "AI Tools"
tags: ["AI Tools", "Agents", "Personal Assistants", "Codex", "Grok Bot", "Claude Code", "Harness", "Predictions", "Developer Philosophy"]
---
# The Personal Assistant Is the Next Interface
None of this is news. Most of what I'm about to describe has been forming in front of us for a while.
But I think it needs to be said plainly.
**The personal assistant is the next interface.**
Not another chatbot. Not another model picker. Not another application with an assistant tucked into its sidebar. I mean something closer to a human personal assistant: one ongoing relationship through which you reach, coordinate, and operate a growing collection of agents, tools, sessions, and machines.
OpenAI's dots and [Instinct](https://instinct.com/) make the shift easy to see. They approach it from opposite ends, and I think together they say more about where the interface is going than either says alone.
This post is the next chapter of three I've already written. [The Back Office / Front Office Split](https://kobi.kadosh.me/blog/2026-02-11-back-office-front-office-split-future-software) describes the system: agents doing the operational work, people doing the judgment. [Agent-First Development](https://kobi.kadosh.me/blog/2026-10-01-agent-first-development) describes how software takes part in it. [Codex Is Becoming an Operating System for Agents](https://kobi.kadosh.me/blog/2026-09-24-codex-operating-system-for-agents) describes the environment where much of the work already happens. This one is about the interface a person uses to operate all of it.
## We put inference inside a conversation
ChatGPT's breakthrough wasn't only that a strong language model became available to everyone. It was the interface.
Instead of learning a model's quirks or writing code against an API, you opened a conversation and started talking. You asked, added context, pushed back, and the answers got better. A familiar interaction model exposed an enormous capability space.
Then something predictable happened. As the capabilities improved, we started using conversations for everything.
One conversation for an architecture question. Another for the feature. Another for researching a product. Another for planning a trip. Several more for trying different approaches to the same problem. And once coding agents arrived, sessions on top of that: a Codex session per repository, a Claude Code session per branch, a research session on the side.
If you were a power user before personal assistants, you know what a day of this looks like. You navigate a dozen sessions, asking things in some, taking actions in others. The hard part was never asking. It was finding your way between them, jumping topics, and keeping some order.
You remember deciding something important a few days ago, but where? ChatGPT? A Codex session? Claude Code? A project? A conversation you started on your phone and never picked up again?
Sometimes you find it, only to realize it has grown so large that continuing inside it doesn't work anymore. The context window is bloated, or that session has already given you everything it efficiently can. So you open a new one, summarize what matters, paste it in, and try to carry on from where you were.
For a few years now, we have been the coordination layer between our own agents.
## Folders, projects, memory: an organization problem
The first answers were the obvious ones.
We sorted conversations into folders. Then came projects, with shared instructions and files: a container that remembers what it's for. Memory followed, so assistants could carry useful facts across conversations instead of depending on whatever fit in one window. Behind it, retrieval got better: something like RAG over your past work, so an assistant could bring established patterns from one session into another.
Most recently, memory became something you can search. An assistant can look through your previous chats and sessions, find the relevant ones, and pull them into the current conversation. In some harnesses a session can read another session, delegate research to a subagent, or start parallel work and come back with the results. I wrote about how far Codex has gone in that direction in the [operating system post](https://kobi.kadosh.me/blog/2026-09-24-codex-operating-system-for-agents).
Look at what all of these have in common.
Folders help you find things. Projects keep context. Memory saves you from repeating yourself. Search recovers work. Subagents spread it out. Every one of them is useful, and every one of them is an **organization tool**: a way to make your own flow work better.
You are still the one who decides which conversation to enter, which context to carry forward, and which agent does what next.
So imagine the same tools, the same organization, operated by someone else. And you have one interface to work with.
## One assistant, many conversations
That is what a personal assistant brings.
Everything you've learned to use over the last few years stays. ChatGPT, Codex, Claude Code, research agents, the browser, the terminal, connectors, MCP servers, CLIs, your own applications. None of their capabilities has to go away.
What changes is who operates them.
Instead of opening five sessions to get to an outcome, you tell your assistant what you need. It decides what context is relevant, which tools or agents fit, where the work should happen, and when it needs to come back to you.
It might start with research, open a dedicated work session, hand implementation to a coding agent, check the result, and bring back a decision or an artifact for you to review. Some of that happens in a cloud environment. Some needs your own computer, with your running systems, your projects, your data. Some needs only a connected app or an API.
You don't need to know which. More to the point, you don't need to be the messenger between them.
And when you come back three days later and ask how it's going, you shouldn't have to remember which session the work happened in. You should be able to just keep talking about the project.
Drawn out, the difference is who sits in the middle.
```mermaid
flowchart TB
subgraph Before[Before: you are the router]
direction LR
U1[You] --> S1[ChatGPT chat]
U1 --> S2[Codex session]
U1 --> S3[Claude Code session]
U1 --> S4[Research agent]
U1 --> S5[Project memory]
end
subgraph After[After: the assistant is the router]
direction LR
U2[You] --> PA[Personal assistant
context, memory, follow-up]
PA --> T1[Chats and research]
PA --> T2[Coding sessions
cloud or local]
PA --> T3[Connectors, MCP, CLIs]
PA --> T4[Other assistants]
end
Before ~~~ After
```
In plain text: before, you connect to every chat, session, agent, and memory store yourself, and you carry context between them. After, you talk to one personal assistant, and it holds the context and memory and routes work to chats and research, coding sessions in the cloud or on your machine, connectors and tools, and even other assistants.
One distinction matters here. The personal assistant isn't one enormous conversation. It's an interface that manages many conversations on your behalf.
A single context window, however large, doesn't replace an organized system of work. We still need separate contexts, specialized agents, persistent artifacts, and places to run things. We just shouldn't have to organize every interaction with them ourselves.
## This is what the personal computer did
The analogy I keep returning to is the PC itself.
Before graphical operating systems, every program was its own world. Each had its own commands and conventions, and you learned each one from scratch.
What the PC and its operating systems did was bring many tools together under one interface. Windows, menus, toolbars, dialogs, the same way to open and save a file. Each application still had its own job: a spreadsheet wasn't a word processor, and neither was a paint program. But you no longer met each one as a stranger. We learned the shared patterns, and the shared patterns made a growing pile of capabilities approachable.
Personal assistants play a related role for AI.
Today, being an effective power user means learning how each model, tool, session, and harness behaves: its strengths, its context limits, its permissions, its integrations, and its very particular ways of failing. That knowledge is valuable. I've built a good part of this blog on it.
But should everyone need it?
The assistant gives us a consistent layer above all of it. The agents and applications underneath stay specialized; the assistant provides the continuity.
And there's one place the analogy breaks, which is the interesting part. An operating system standardizes how _you_ operate the applications. You still pick the program and do the clicking. A personal assistant picks the program and does the work. Most of what it does is something you could have done yourself; it just does it faster, and without you having to hold the whole map in your head.
It doesn't only standardize how we operate tools. It starts operating them for us.
## dots make the harness reachable
That is what I find so interesting about OpenAI's dots.
The [help center](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot) describes a dot as "an always-on agent in ChatGPT that can take on ongoing responsibility and keep making progress between conversations." It has its own cloud computer, works across the apps you connect, remembers context, and "can create cloud tasks in Codex cloud environments." [Engadget](https://www.engadget.com/2272230/dots-are-openais-new-personal-agents-and-soon-youll-be-able-to-control-several-of-them/) adds the part that matters most to me: it's possible to connect a dot to your own PC, "allowing them to control it on your behalf and work alongside you."
Put those together and look at what sits behind a fairly simple-looking assistant: the whole ChatGPT and Codex harness. In my use, a dot runs the show by spinning up as many sessions as it needs. A research session here, a subagent inside an existing Codex session there, a work session for the actual change. And the Codex sessions on my machine can reach what Codex can reach: running systems, the projects I'm building, data, APIs, connectors, MCP servers, CLIs, the terminal.
None of those capabilities are new to me. I've used every one of them directly, and as a power user I knew how to combine them across sessions. What's new is the arrangement. I don't operate the harness anymore. The assistant does, and I talk to the assistant.
I don't have to explain how to use each tool before I describe an outcome. I don't have to know how many sessions it will take.
It isn't unlimited, and it isn't magic. What a dot can do depends on what you connect, what you allow, and which environments are available. Tasks it starts in Codex or in ChatGPT Work, OpenAI's agent for longer research and deliverables, still count against those products' usage limits. Availability is still narrow, and at launch, Engadget reports, you get one primary dot.
But the direction is clear. We're moving from operating our AI harnesses to having an assistant operate them for us. That is a real change in the relationship between a person and their software.
## The interface is still catching up
Here's the caveat: we haven't solved the interface yet.
Right now it can feel clunky, especially when you try to follow several unrelated topics at once. An ongoing conversation is convenient until it turns into one long stream of unrelated work. A software project, a doctor's appointment, a research question, and a recurring chore can all belong to one relationship with your assistant. They don't all belong in one transcript.
That's why I find dots in Slack so interesting. OpenAI shipped [Slack and Microsoft Teams integrations](https://www.engadget.com/2272230/dots-are-openais-new-personal-agents-and-soon-youll-be-able-to-control-several-of-them/) with the launch, and Slack already has the structure a single chat lacks: channels, threads, mentions, notifications, conversations scoped to a topic. In my use, that's how a dot brings order to different subjects: a channel per area, a thread per piece of work, the same assistant in all of them.
It isn't a perfect interface for an assistant. But it gives you working primitives for keeping discussions apart, without inventing a whole new application model.
So I can talk to the same assistant from my phone, from the desktop, and from a set of topic-specific Slack threads. The assistant stays the same. The subjects and the surfaces change.
That's a far more promising direction than forcing everything into one endless chat. And I expect these interfaces to get much better. We'll need ways to see the work in flight, revisit decisions, know which agents are waiting on us, and understand what changed while we were away. And we'll need all of that without rebuilding the very complexity the assistant was supposed to remove.
The goal isn't one conversation. It's one coherent relationship with the systems doing your work.
## Instinct comes at it from the other side
If dots show what happens when an assistant gets access to a powerful existing harness, [Instinct](https://instinct.com/) shows almost the opposite.
Instinct hides the box entirely. You text it, and it uses its own computer and phone to get things done. No new workspace to learn, no sessions to manage, no expectation that you know the difference between an agent, a tool, and a coding environment. Whatever happens inside, it just does, and it talks to you the way a human assistant would over chat. There are limits to how far the technology goes today, but the model is right, and it brings some fresh air.
When you ask a person to set up a meeting or look into a problem, you don't tell them which browser tabs to open, how to keep their notes, or how many calls to make. You give them the outcome you want and the constraints. Instinct brings that model to software.
It also has a capability a human assistant would struggle to match. Its Trusted Person network lets Instinct agents [talk to each other directly](https://pulse2.com/instinct-raises-1-billion-series-c-at-10-billion-valuation/), over what the company calls its Instinct-to-Instinct protocol, to "coordinate schedules or other arrangements" on their users' behalf. Two people no longer have to ask their assistants for information and then act as the relay between them. The assistants coordinate, within the permissions each person set.
Scheduling is the obvious case, but the pattern goes well past calendars. And this is the kind of capability that makes an assistant more than a chatbot with a nice personality.
Different strengths, then. dots show the potential of a broad execution environment and an existing ecosystem. Instinct shows how little of that environment you may ever need to see. I suspect the strongest assistants will end up combining both.
## Dispatch and the Primary Bot point the same way
The other labs are moving in this direction too, and it's worth being precise about where they are.
Anthropic's [Dispatch](https://code.claude.com/docs/en/desktop#sessions-from-dispatch) is "a persistent conversation with Claude." You message it a task, and it either does the work itself or decides the task is development work and starts a Claude Code session on its own, with a push notification on your phone when the session finishes or needs approval. That's a real capability, and it's the same shape: one conversation in front, work sessions behind it.
But in my experience it hasn't delivered on that promise. It feels like a remote control for a work session rather than someone running the show. What I want goes past invoking a powerful session from my phone: an assistant that takes ongoing responsibility for several independent areas of work, keeps their contexts straight, and comes back when something actually needs me. Dispatch is missing too much of what a personal assistant needs underneath, and too much of the focus on being one. Claude has most of the underlying technology, so I'd be surprised if this is Anthropic's last word.
Grok Bot is a different category, and I don't think it's aiming at the same thing. I've spent a lot of time with it, including [giving its bots hands on my Mac](https://kobi.kadosh.me/blog/2026-10-02-latch-giving-grok-bot-hands-on-my-mac) and [driving Grok Bot from Grok Bot](https://kobi.kadosh.me/blog/2026-10-08-latch-v2-self-heal-local-exec). Its model is a team: durable bots with names and responsibilities, each with tools, able to message one another. That's valuable, and it has its own advantages.
Its answer to the personal assistant is the Primary Bot. The [changelog](https://x.ai/changelog/bot) says your primary Bot, marked with a star, will now spot work it can take off your plate and offer to handle it. Notice the word: OpenAI's [announcement](https://openai.com/index/introducing-dots/) tells you to "start with your primary dot." Both labs know where the center of the relationship is.
In my experience, though, the Primary Bot doesn't yet behave like a primary bot. It's a featured bot in a collection of bots. It may feel more approachable, but in practice it's like any other bot, not the interface that reliably takes responsibility for running the whole system. Being able to message other agents isn't the same as owning the job of making sure their work moves forward without you managing every handoff.
I expect the Grok Bot team to close some of that gap. But I wouldn't treat the Primary Bot and a dot as the same experience just because both are described as proactive.
## What makes something a personal assistant
The distinction matters because "assistant" has been used loosely for years.
Almost every ecosystem now has something it calls an assistant. Usually it's a chat interface to that ecosystem: ask a question, get some information, maybe trigger a function. Useful, absolutely. But most of them don't have the tools. They can't retain memory across your work. They can't talk to other sessions. They can't work locally, on a computer with a browser and a terminal.
Those tools are what make a personal assistant different, because they change the contract. A chat assistant hands you knowledge and asks what you'll do with it: _here's the information, now go do something._ A personal assistant asks what it can do for you: _this is my need; can you get it done?_
Take a concrete request:
> Find the recruiter messages I haven't answered, pick out the opportunities worth exploring, and draft replies.
A chat assistant gives me advice on how to approach that. An application's assistant searches my inbox and writes a summary. A personal assistant takes the process: finds the threads, understands the context, separates the good opportunities from the rest, drafts the replies, and brings me the decisions. When another recruiter writes next week, it continues the same process without me rebuilding it.
The question isn't whether a system can run a particular function. It's whether I can delegate an outcome and reasonably expect it to follow through.
That takes more than inference. It takes memory, tools, execution environments, permissions, feedback, and continuity. In other words, [a harness](https://kobi.kadosh.me/blog/2026-09-15-harness-driven-development).
dots are doing this unusually well, and they can be extended beyond what ships in the box. That's a post of its own, and I'll write it.
## Delegate the work, keep the accountability
There's an obvious risk in all of this. Putting more capability behind one interface also concentrates access and authority. An assistant that can read your documents, send your messages, drive a browser, run code, and direct other agents can get a lot done. It can also make mistakes across a lot of software.
So the interface can't just hide everything behind a reassuring "Done."
I want the assistant to manage the complexity of execution, not hide its consequences. I should be able to see what was done, which actions were taken, and what's still open. I should be able to tell a proposal from an approved action, and a reported success from a verified one. When something needs my judgment, it should come to me clearly.
The products are drawing some of these lines already. OpenAI's [announcement](https://openai.com/index/introducing-dots/) says "Certain sensitive tasks, such as changing a password, always stay with you." Grok Bot's [documentation](https://docs.x.ai/grok-bot/approvals-security-and-privacy) warns not to treat separate bots as a security boundary. I made the longer case for evidence over summaries in [Desired-State Development](https://kobi.kadosh.me/blog/2026-10-22-desired-state-development), where the personal assistant is the one holding the loop.
The best personal assistants won't be the ones that never ask permission. They'll be the ones that know when permission matters, hold the boundaries, and stop interrupting everywhere else. A person can delegate work without delegating accountability. Our assistants have to preserve that.
## My prediction: every frontier lab will ship one
I think personal assistants will become the main way we use what the frontier labs build, and that each of them will ship its own: one place that exposes all of its capabilities.
Not because everyone wants a digital companion. The motivation is more practical.
We've built extraordinarily capable models, tools, and harnesses. Using them to their full potential still takes more coordination than it should. Someone has to know what's available, keep the context, choose where the work runs, follow up on what's unfinished, and present the result. For a long time, that someone was you. The assistant is the natural place for that job to move.
The assistant will grow into the native harness underneath it. Every capability the lab adds to its coding agent, its computer use, its connectors, becomes something the assistant can reach for. And it won't stop at one provider: assistants will coordinate with specialized agents running somewhere else entirely, and, as Instinct already shows, with other people's assistants.
That raises the question of who owns the relationship. If my assistant becomes the main way I operate software, I should be able to change the tools underneath without losing my history, my preferences, or my work in progress. In the language of the [back office / front office split](https://kobi.kadosh.me/blog/2026-02-11-back-office-front-office-split-future-software), the back office becomes an interchangeable set of services and agents, and the assistant becomes the front office, where I state intent, check progress, and decide. The software underneath has to become something an assistant can use, which is the whole argument of [Agent-First Development](https://kobi.kadosh.me/blog/2026-10-01-agent-first-development).
dots are fresh, and they're leading. I'm fairly sure we'll see more personal assistants that take on an outcome and follow it through the way they do.
## Stop managing the conversations
We spent the first years of conversational AI learning to talk to models. Then we learned to organize conversations, keep context, work across sessions, run agents, and build harnesses around all of it.
Those skills don't become worthless. But operating all that machinery by hand isn't the destination.
If the personal assistant works, something quite ordinary happens. You stop asking which conversation had the work in it. You stop opening a new session just to carry what the last one found. You stop being the one who tells every agent what another agent already learned.
You say what you're trying to do, come back when you want, and expect your assistant to know enough about the work in flight to help you continue.
The first revolution made inference conversational. The next one makes the conversations something we no longer have to manage.