Squire: Giving AI a Place to Work

The first wave of AI products taught us to chat with models. Open a box, paste in some context, ask a question, copy the answer back into whatever we were doing.

That was useful. It still is useful.

But it already feels old.

The next step is not a better chatbot. It is not another fake employee with a job title. It is not a swarm of agents pretending to be a company. The next step is putting AI inside the workflow, where the work already lives.

I call this idea Squire.

Squire is not an AI chatbot, per se. It is a context-engineered awareness service that runs on your computer. Its job is not to answer random questions. Its job is to understand the pain points inside an app and help solve them there.

A squire is present when needed and unseen when not. It carries the tools. It prepares the work. It does not take over the kingdom.

That is the shape I want from local AI.

Chat is the wrong center

Chatbot interfaces made sense in 2022 and 2023. They were the easiest way to expose large language models to people. But as an interface for real work, chat has an obvious problem: it pulls you out of the thing you were doing.

If I am managing a music release, I do not want to leave my music project manager, open a chatbot, paste in album notes, explain the campaign, ask for copy, copy the result back, clean up the formatting, and repeat that process for every field.

I want to click the brain button.

The app already knows the album title, the artist, the release date, the previous campaign notes, the platform requirements, and the empty fields that need copy. The AI should not need me to reconstruct that context manually. It should be able to read the app's own world and help inside that world.

That is the difference:

Chatbots move the user out of the workflow. Squire moves the model into the workflow.

The sandbox is not just about safety

When people hear sandbox, they usually think about security. That matters, but it is not the whole idea.

The sandbox is a defined space where the AI can move around and be useful. It is not just a cage. It is a shape.

An AI system cannot create meaningful things outside the structures it understands. If it generates something that does not fit the app's data model, workflow, or conventions, then the user is stuck translating again. That defeats the point.

A useful sandbox gives the AI context, constraints, and affordances. It tells the model:

• Here is the app state.
• Here are the files.
• Here are the available actions.
• Here is what a valid output looks like.
• Here is what you can suggest.
• Here is what you cannot do directly.

Inside that space, the AI can be much more effective because it is not guessing from a blank chat window. It is working inside a known system.

Giving the AI toys

The best way I can describe this is: give the AI toys to play with.

A toy might be a local script. A small API. A file reader. A draft generator. A test runner. A project scaffolder. A browser automation tool. A content analyzer. A command that fills in missing metadata. A tool that creates another tool.

People are trying to formalize this kind of thing with MCP servers, skills, tool manifests, and communication layers. Some of that is useful. But I think a lot of it is already too heavy.

If the AI is running inside the app's brain, why does everything need to become an external protocol problem?

If the system changes, the MCP layer has to change. Then the versions have to match. Then the tools need to talk to each other. Then the abstraction becomes the thing you are maintaining instead of the work you wanted done.

Sometimes the simpler answer is better: a local context, a few readable structures, a heartbeat, a cron job, and the ability to create or modify small tools as needed.

Let the system be extensible from inside itself.

Self-extensible software

The interesting part of Squire is not just that it can use tools. It is that it can help create new ones.

Imagine a local app that can spin up a tiny V8 or Node runtime in less than a second, almost like a local Cloudflare Worker. The AI sees a repeated need, proposes a small local API or script, writes it, tests it, and registers it as something the app can use later.

That is more interesting than a static tool list.

The app starts with a few basic abilities. Over time, it develops more. Not because some central platform predicted every possible use case, but because the user's actual workflow revealed what was missing.

This is what self-extensible means in practice. Not an AI with unlimited agency. Not a runaway process making decisions on its own. Just a system that can notice gaps in its own environment and propose new capabilities that fit the existing structure.

The human still approves the important parts.

Read mostly, recommend first

People will hear this and immediately worry about safety. That is fair.

But everything is unsafe. Everyone gets pwned eventually. The answer is not to pretend you found the one perfect architecture that makes you immune. The answer is to posture as high as you reasonably can and stay honest about the risks.

For Squire, that means read-mostly by default.

It can read project data. It can analyze. It can draft. It can fill internal fields. It can recommend. It can rank options. It can prepare work.

But it should not send the email. It should not delete the inbox. It should not publish the post or ship the release unless the user has explicitly built and approved that capability.

For example, I do not want Squire inside my Gmail randomly taking action. But I do want it to draft an email inside my own system, using the context it has. Then I can do the last mile myself. Copy it, review it, send it.

That boundary matters.

Squire is not there to replace judgment. It is there to reduce friction before judgment.

The brain button

A concrete example: a music project manager.

You are preparing an album release. The app has all the project data: title, artist, track list, release date, notes, assets, maybe previous copy, maybe target platforms.

There are a dozen annoying fields that need to be written: short description, long description, social captions, press blurb, email announcement, platform-specific text, maybe a release checklist.

Instead of exporting all that into a chatbot, you click the brain button.

Squire reads the available context, identifies the missing media copy, drafts it in the right fields, and maybe ranks what still needs attention. It does the prep work where the prep work belongs.

That is the product experience I care about.

Not ask the AI a question.

More like: the app noticed the unfinished work and prepared a useful next version.

A nervous system for solutions

The best metaphor may be a nervous system.

Pain is a signal. It tells you something is wrong or something needs attention. But pain by itself does not solve anything. It just interrupts you.

Squire is like a nervous system for solutions.

It listens for the pain in the workflow: the empty field, the repeated task, the awkward copy-paste loop, the thing you keep avoiding because it is tedious. But instead of only surfacing the pain, it prepares a solution sensation.

• Here are the drafts.
• Here are the missing pieces.
• Here is the next action.
• Here is the tool I can create to make this easier next time.

That is a different kind of software.

Beyond foundation training data

The bigger future is contextual AI that goes beyond foundation training data.

The model is important, but the model is not enough. The value comes from the live context around it: the app state, the user's work, the local files, the history, the constraints, the data structures, the tools, and the permissions.

Developers have not fully internalized how fast this paradigm is changing. A lot of people are still thinking in terms of chatbots, MCP plumbing, skills, and fake company-role agents.

I think the better direction is simpler and more central.

• Build a good context.
• Make it efficient for tokens.
• Make it effective for results.
• Keep it easy to maintain.
• Let the AI operate inside the app, not outside it.
• Let it recommend more than it decides.
• Let it extend the system where the system needs extension.

The next interface is not a chat box.

It is an app that can feel where the work hurts, and quietly prepare the next useful thing.