Porter

Most AI products begin with a blank text box. Porter begins with the screen in front of you.

AI agents are becoming more capable faster than they are becoming accessible.

Powerful agents already exist, but most are still built for people willing to operate them. Users are asked to choose models, connect tools, install integrations, configure workflows, manage prompts, and repeatedly explain context their computer already has.

That is no longer primarily an intelligence problem.

It is an access problem.

Agents may be the future of computing, but today, using one is still a technical skill. The students, families, caregivers, and everyday computer users who could benefit most are often the least interested in becoming agent engineers.

I built Porter to make that skill disappear.

Porter is a native, OS-level personal agent for macOS. Say “Hey Porter” or press ⌘K from any application, describe the outcome, and Porter appears over the work already in progress.

It sees the exact window in front of you, understands the visible interface, operates the computer through real mouse and keyboard input, continues across applications, verifies the resulting state, and remembers user-controlled context that can make the next task require less explanation.

Porter does not give people another place to use AI.

It turns the computer they already use into the agent interface.

One sentence can replace an entire application

A job seeker has a listing open and says:

“Hey Porter, apply to this job.”

Porter already knows what “this job” means because the listing is on screen.

It reads the role and requirements, navigates to the application, and begins completing the form. It can use information the user has deliberately made available through Porter’s memory or through a resume already on the Mac. It works through contact information, education, employment history, skills, links, dropdowns, multi-page forms, and role-specific written questions.

It does not replay a recorded macro. It observes each page as it appears, acts on the current interface, waits through loading states, and adjusts when the next screen differs from what it expected.

Porter fills only what it can ground in approved information. It does not invent a qualification. It flags anything that requires the user’s judgment, verifies the completed fields, and stops at the final submission boundary so the person can review and submit the application.

One sentence can replace dozens of fields, repeated uploads, copied dates, context switching, and an hour of mechanical work.

More importantly, the next application can require even less instruction. Porter can reuse approved facts, writing preferences, document choices, and corrections from previous successful tasks.

This is Porter’s central product loop:

Every successful interaction can remove instructions from the next one.

Porter is not a collection of workflows

The job application is not a special job-board integration.

It is one example of Porter’s general computer-use loop.

Porter is designed around a simple boundary: if a task can be completed through a visible macOS interface with a mouse and keyboard, it belongs inside Porter’s capability surface.

Porter can inspect what is visible, click semantic controls or visual targets, type into focused fields, use ordinary keyboard shortcuts, scroll through interfaces, wait for applications to respond, switch between applications, and observe the result before deciding what to do next.

That same loop can work through a browser, document editor, spreadsheet, settings panel, file picker, message composer, learning platform, travel site, administrative portal, or an unfamiliar application that has never been given a Porter-specific integration.

Applications do not need to know that Porter exists. The interface they already expose to a person becomes the action surface.

Examples such as teaching, research, drafting, shopping, form filling, settings changes, file management, and messaging are therefore not Porter’s capability list.

They are evidence of a capability model whose surface is the computer itself.

When Porter cannot verify progress, it stops instead of pretending the task succeeded. The current build is still a prototype, and not every interface is equally reliable, but its architecture is general rather than organized around a finite gallery of scripted demos.

The problem Porter solves is agent access

Most agents expose their machinery.

The user sees tools, connectors, integrations, prompts, workflow graphs, and configuration. Even when the underlying intelligence is powerful, accessing that intelligence remains work.

Porter hides that machinery behind an interaction ordinary people already understand:

Leave the task visible.
Say what outcome you need.
Watch Porter work.
Review consequential decisions.

Once Porter is installed and its macOS permissions are granted, there is no per-application setup and no workflow to build for each new task. The screen supplies the context. Natural language supplies the intent. The applications already on the Mac supply the tools.

The user does not need to translate “this form,” “that question,” “the chart I am looking at,” or “the job on this page” into a carefully constructed prompt. Porter begins inside the task that is already happening.

The product is not a simpler control panel for operating an agent.

It removes the control panel.

Porter learns the person, not a sequence of clicks

Macros become more fragile over time because they remember where things used to be.

Porter becomes more useful over time because it remembers how the user prefers successful work to be done.

Its memory can form a user-owned context layer containing approved facts, preferences, recurring choices, writing conventions, document selections, and corrections. That context can make complex tasks—from preparing an application to drafting a message or completing a recurring form—collapse into a much smaller request.

Porter’s memory is local, visible, attributable, and removable. A person can inspect what was remembered, understand where it came from, override it in the current request, or forget it entirely.

Most importantly:

Memory can provide context, but it never provides authority.

Remembering someone’s address does not grant permission to submit a form. Remembering a preferred store does not grant permission to make a purchase. Remembering a recipient does not grant permission to send a message.

An explicit instruction always overrides a learned default, and consequential actions still require a fresh approval or remain with the user.

Porter becomes easier to instruct without silently becoming harder to control.

Not a chatbot. Not a macro. Not a workflow builder.

Chatbots wait for the user to bring them context.

Macros assume the interface will not change.

Workflow builders still ask the user to become the programmer.

Porter begins from a different model:

natural language defines the outcome;
the current screen supplies immediate context;
macOS provides the action surface;
personal memory supplies approved continuity;
fresh observation replaces recorded coordinates;
successful outcomes reduce future instruction; and
the reasoning system proposes actions, but Porter controls whether they are dispatched.

The architectural surface is not a finite list of integrations.

It is the visible computer interface a person already knows how to use.

New abilities do not require a new user experience each time. They must instead work through the same invocation, observation, action, memory, verification, and authority system.

The hard part was not making an AI click

The hard part was making general computer control trustworthy enough to place beside someone’s personal work.

At invocation, Porter binds the request to the exact application and window the person was using. ScreenCaptureKit supplies a protected visual observation, while the macOS Accessibility tree supplies semantic controls and structure.

The reasoning layer receives the task and protected observation, then proposes one typed, bounded action.

It does not receive unrestricted control of the cursor, keyboard, shell, filesystem, credentials, or arbitrary URLs.

Local Porter code asks a more important question than “What action was proposed?”

It asks:

Is this exact action still grounded in the current screen, permitted by policy, and inside the authority the user granted?

Before dispatch, Porter checks that the application and window are still current, the observation is fresh, the referenced element or visual target is grounded, the action is structurally valid, and the task remains within its step and safety budgets.

It then performs one action and observes again before continuing or claiming success.

observe → propose → validate → act → verify

Stale observations are rejected. Repeated actions without visible progress are stopped. Sensitive controls receive stricter treatment. Uncertain outcomes do not trigger blind retries.

Purchases, application submissions, account creation, payments, uploads, deletions, and other irreversible external commitments remain outside ordinary computer-use authority. Porter prepares as much reversible work as possible, then stops for review unless a dedicated capability has received an exact, single-use, expiring approval.

A new wake request or physical keyboard and mouse input can interrupt computer control.

Porter’s power comes not only from how much it can attempt, but from how precisely it knows when it must stop.

Designed as part of the Mac

Porter is a native SwiftUI and AppKit application, not a browser wrapper or chat interface placed beside the real work.

It has an always-available menu-bar presence, local wake-word detection, streaming speech recognition, and a system-wide ⌘K command surface that can appear over the user’s current Space—even above a full-screen application—without dragging the person into a separate dashboard.

A visible activity treatment makes it clear when Porter is listening or controlling the computer. Its native surfaces expose memory, permissions, approvals, activity, and safety controls without turning the product into an agent-development environment.

Porter observes the exact task-bound window rather than the entire composited display. Screen images are consumed for the active task rather than retained in the activity history. Personal memory remains local and inspectable.

The current project is a runnable native application supported by hundreds of native tests spanning computer use, observation, coordinate grounding, voice, memory, approvals, shopping, tutoring, planning, verification, and runtime behavior.

The goal is coherence. Whether Porter is completing a form, teaching from the screen, researching across applications, drafting content, changing a setting, or preparing an action for approval, it should feel like the same calm system capability.

Built solo with Codex and GPT-5.6

I built Porter as a solo developer.

Codex was not used to generate a one-shot mockup. Using GPT-5.6 through Codex, I treated it as a sustained engineering collaborator across the complete development cycle.

Together, I iterated across the native SwiftUI and AppKit product, offline voice runtime, ScreenCaptureKit observation, Accessibility semantics, multimodal action contracts, coordinate conversion, real mouse and keyboard dispatch, personal memory, cross-application execution, approval systems, verification loops, compiler failures, live test harnesses, and adversarial safety hardening.

The development loop repeatedly moved through:

specify → implement → compile → test on a real Mac → attack the boundary → tighten the contract

Codex was especially valuable for tracing failures across asynchronous macOS frameworks, reconciling the coordinate systems used by model images, windows, and input events, evolving purpose-built demonstrations into a general computer-use loop, and converting failures from real applications into regression tests.

I made the defining product and engineering decisions:

Porter should be screen-native.
Natural language should replace workflow configuration.
The operating system should be the integration layer.
Memory should remove repeated context without granting authority.
The reasoning system may propose actions but never directly control the computer.
Porter must verify outcomes rather than merely predict that an action worked.
Irreversible decisions must remain with the user.

GPT-5.6’s role was in the engineering process through Codex, helping me turn an ambitious OS-agent idea into a coherent, working native product. Porter’s runtime reasoning is separated from its local authority system through typed contracts; the product thesis does not depend on exposing a particular runtime model to the user.

What Porter demonstrates

Porter demonstrates that a general-purpose agent does not need to present ordinary users with a dashboard full of integrations, a tool marketplace, or a workflow canvas.

It demonstrates that the current screen can be the prompt, the operating system can be the integration layer, and a spoken outcome can be enough to begin a real task.

It demonstrates that applications do not need custom agent support before an agent can work through them.

It demonstrates that personalization can make an agent require dramatically less instruction over time without silently granting it more authority.

Most importantly, Porter demonstrates a path for distributing agent capability to people who will never build an agent themselves.

The breakthrough is not merely giving an agent another capability.

It is making general agent capability accessible through an interface everyone already knows how to use.

What I learned

The model is not the product.

The product is invocation, context, continuity, perception, memory, authority, recovery, and proof that the promised outcome actually happened.

I also learned that the best measure of personalization is not how much information a system can retain.

It is how many instructions the user no longer has to repeat.

And the best measure of accessibility is not how simple the agent configuration becomes.

It is whether configuration disappears from the user’s life entirely.

Porter does not try to make everyone better at operating agents.

It makes operating an agent stop being a skill.

What’s next

The next step is to increase Porter’s reliability and reach without widening unchecked authority: longer cross-application tasks, richer user-defined policies, more expressive personal context, stronger recovery across unfamiliar interfaces, signed distribution, private on-device reasoning options, and shared modes for families and caregivers.

The long-term vision is simple:

The most powerful agent should also be the easiest one to access.

People should not have to assemble tools, connect every application, design workflows, or learn prompt engineering to benefit from agentic computing.

They should be able to say what they need, see the work happen in the applications they already trust, and remain in control of every consequential boundary.

Speak. Porter appears. The workflow disappears.