The next step is even bigger: with AI, you won’t just learn and sell from anywhere — you’ll be able to operate from anywhere. Build, manage, automate, and run entire businesses remotely.

AI becomes truly transformative when it stops being something you visit and becomes something that stays with you. Persistent memory. Persistent identity. Persistent understanding. Not an assistant for a session. An intelligence for a lifetime.

The computer of the future may not feel like a computer. No apps to navigate. No folders to organize. No software to learn. You express an intention, and your AI constructs the tools, interfaces, and workflows needed to make it real.

The endgame of AI isn’t a better chatbot. It’s an intelligence that grows with you for years. It knows your world, remembers what matters, understands what you’re trying to become, and can actually act alongside you. A second intelligence in your life.

The model shouldn’t be the AI. Models will change constantly. The AI should be the persistent layer above them: memory, identity, permissions, tools, relationships, history. Models are replaceable brains. The AI is everything that persists.

I don’t think the future is “AI inside every app.” I think the future is the opposite: Your personal AI generates the software, interface, and workflow you need in the moment. Static apps may eventually feel like static webpages do today.

A million-token context window is not memory. Memory means knowing: what to keep, what to forget, what to compress, what to retrieve, and what should change your future behavior. Persistent AI needs a memory architecture, not just a bigger prompt.

Two agents may be able to communicate and still be unsafe to connect. The harder problem is delegation: what authority crosses the boundary, for how long, and who remains accountable for the action? A2A without scoped delegation feels incomplete.

Planning has a cost: latency, tokens, complexity, and more places for a run to go wrong. For simple requests, execution should be direct. Planning should appear only when the structure of the task actually demands it.

Durable AI workflows need something more fundamental than a scheduler: traceable events. If every meaningful action in a system can become a typed event, then today’s endpoint can become tomorrow’s trigger—without rebuilding the product around each new automation.

A personal AI shouldn’t remember everything. It should remember what changes how it understands or helps you—and retrieve the rest when needed. The hard problem in AI memory isn’t storage. It’s deciding what deserves to become part of the persistent self.

A personal AI probably shouldn’t have one global permission set. The same AI can be “me” across DMs, workspaces and apps while its authority changes at every boundary. Persistent identity and persistent authority are different problems.

A planner shouldn’t be the default state of an AI agent. If the next action is obvious, planning is overhead. Planning should appear when the objective becomes complex enough to justify decomposing it. Maybe “when should the agent think ahead?” is a runtime decision, not a prompt instruction.

I’m starting to think a serious agent runtime needs an event model, not just a tool model. If every meaningful action is traceable as an event, the same system can support workflows, approvals, retries, schedules, debugging, and triggers without each integration inventing its own machinery.

I suspect the hard part of personal AI memory isn’t storing more. It’s deciding what deserves to survive. Every interaction produces possible memories, but persisting all of them creates noise and giant contexts. Forgetting may need to be a first-class operation in AI architecture. Why this is worth posting: Memory retention and intentional forgetting are still-open design problems that can spark substantive discussion among people building persistent agents.

I’m increasingly skeptical that an agent should enter every task with its full toolset exposed. A better architecture may be: intent → capability discovery → permission check → tool loading → execution Tool discovery isn’t just a UX detail. It’s part of context engineering. Why this is worth posting: It raises a concrete architecture question around token efficiency, permissions, and agent runtimes that engineers building MCP/tool systems can actually debate.

Personal AI may change what an “app” even is. Today, humans open apps and navigate interfaces to access capabilities. Tomorrow, AI may discover and invoke those capabilities directly. The app stops being the interface. It becomes infrastructure.

AI can already write, reason and generate code. The missing piece is getting it to actually operate. Context. Permissions. Tools. Execution. Memory. All of these are still fragmented across different apps