OpenInstinct: an AI assistant that works from your texts

A useful personal assistant needs to do something with a request. If you ask for a ticket, a booking, or a completed form, the work usually ends inside a website: choosing an option, signing in, entering details, and checking the result.

OpenInstinct, from Merit Systems, connects that work to a familiar starting point: an iMessage thread. You send a request, and an agent uses a browser to carry it out. Its source is public, and you can deploy the application into your own account.

For businesses, the interesting part is how the project separates the conversation, browser work, saved credentials, and permission to spend. Those are useful design choices to study even if a personal assistant is not the product your team needs.

This article examines the repository at commit 0c2a7c6, checked October 6, 2026. We reviewed documentation and selected implementation files; we have not run a deployment or audited its security. The README explicitly says: “This is not software intended for production use.”

What OpenInstinct brings together

The project combines several pieces that are often discussed separately in AI demos.

The project site illustrates bookings, shopping, and forms. Those examples describe the intended experience; they are not success rates measured by Looski. In the source, the browser workflow runs a separate worker and validates its returned result against a completion schema.

That separation is useful. The conversation can express the task and resolve ambiguity, while the browser worker concentrates on a bounded assignment. A well-defined result also gives the surrounding application something more useful to handle than an unstructured claim that the work is done.

Using a password does not require putting it in a prompt

OpenInstinct’s vault autofill is the most instructive mechanism in the project.

The fill-from-vault tool accepts a browser-session identifier and a saved-item identifier. It checks that the browser belongs to the caller’s scope, retrieves the selected vault item, and obtains the current page origin. The application then passes the values through its native autofill path. The tool returns a success result, item type, origin, and count of filled fields rather than the secret itself.

The general pattern is straightforward: let the model choose a permitted operation; let application code handle the sensitive value.

For a business workflow, that could mean letting an agent select a supplier login while a separate component fills the credentials. The agent does not need a password pasted into its instructions to attempt that task.

This is a property of a particular data path, not proof that every secret is invisible throughout the system. The application, browser, and destination site still participate in using the credential. The README also notes that payment credentials from the optional Link integration can appear in stored Eve tool results. That distinction matters when evaluating the vault and wallet together.

Permission to connect is different from permission to act

OpenInstinct’s Link spend-request tool requires the purchase-approval flag to be true. The README explains that connecting a wallet does not approve a purchase; each spend request requires approval in Link.

That is a useful pattern for business agents. Access to an account can make a task possible without granting unlimited authority to commit money or change records. The approval should describe the actual proposed action, including the merchant, items, and final total.

Do not assume that every integration implements the same approval boundary. The project’s landing page describes approval for email and calendar changes, while the current README says user-requested operations run without an additional Eve tool approval. The Gmail tool implementation also exposes different capabilities by execution mode: interactive conversations can send mail, while scheduled workers receive search and read tools.

For anyone adapting this design, inspect the path for each consequential action. A general promise that an assistant “asks first” is less useful than knowing which component enforces the decision and what request the person actually approves.

Remembering work should not silently restart it

The workstream memory implementation treats saved notes as context rather than authorization. It distinguishes recording progress from starting a job, scheduling work, or approving an action.

Consider an assistant helping prepare a supplier order. Remembering the chosen products and an unresolved delivery question should help the next conversation resume. It should not turn “we discussed this order last week” into permission to place it today.

That distinction becomes more valuable as agents work across several conversations. Context preserves continuity. Authorization establishes what may happen next. A system needs both, with an explicit relationship between them.

Self-hosting here still uses a cloud stack

The documented deployment runs in your Vercel account and connects Kernel cloud browsers, Neon Postgres, private Vercel Blob storage, Linq for iMessage, and Vercel AI Gateway for models. Google Workspace and Link require additional setup.

This gives the operator control over the application deployment and source. It does not establish that messages, browser sessions, stored data, or model inference remain on a local machine. Even the documented local-development flow still uses Kernel and AI Gateway.

The model choice is also more specific than “any model” might suggest: the project site describes choosing among models available through Vercel AI Gateway. A local-only deployment would need its own implementation and verification; it is not the documented default.

Operating costs extend beyond the model. The current README requires Vercel Pro for the every-minute schedule and describes separate service usage charges. Free tiers and initial credits do not establish a zero-cost installation. Anyone evaluating the project should budget the complete workflow, including browser sessions and messaging.

Our guide to a testable data boundary provides a way to ask where each part of that workflow runs and which services receive its data.

What a business should take from it

OpenInstinct is a useful open-source reference for a specific kind of assistant: one that receives ordinary requests, uses real services, and carries context between tasks. Its MIT license makes the implementation available to inspect and adapt under the license’s terms.

For an initial experiment, choose one bounded job with a result a person can verify. Preparing a supplier cart for review is easier to evaluate than delegating purchasing in general. Define the permitted account, products, spending limit, stopping point, and evidence of completion before running it.

Then test what happens when the request is ambiguous, the site changes, or the agent stops halfway through. The useful measure is whether the workflow reaches a correct, reviewable outcome and can recover when it does not.

The strongest lesson is architectural: make the request easy to express, keep browser work bounded, handle credentials through dedicated code, and tie consequential actions to explicit permission. OpenInstinct puts those design questions in code that others can examine. Turning them into a dependable business process still requires evaluation and operating discipline.