My research setup has to work without an AI agent

I want to close every AI assistant and continue working. I’d lose speed. I shouldn’t lose my understanding of the project, access to my sources, or the ability to run the tools that got me this far. My work involves understanding research quickly, trying things, and figuring out what my own results mean. I want frontier models helping with that, without making one company’s app a prerequisite for understanding my work.

This space is changing quickly. I’ll be adding to and replacing parts of this setup soon. This is a snapshot of what’s useful to me today, and why I think it’s worth spending time configuring these tools around your work.

Here’s what that means in practice:

• The friction: context that gets trapped, opaque actions, and more integrations to maintain.
• The requirement: evidence I can inspect and work I can continue myself.
• The setup: local tools, on-demand skills, and the audit trail I’m still missing.

Where agent workflows lose me

These are the things I want my setup to avoid:

• Having to ask the agent what happened. A confident summary doesn’t tell me which paper version it read, what command failed, or which file actually changed.
• Rebuilding context every time I switch. A decision buried in one app’s history is work I have to recover before I can make progress elsewhere.
• Adding an account to access data I already have. Another API key, relay service, or sync layer needs a reason to exist when the original application already keeps a usable local copy.
• Producing more work than I can review. Ten investigations aren’t useful if I can’t tell which result changes my next decision.

“Memory,” “context,” and “sync” can be useful. I want to inspect their records, correct them, export them, and decide what gets shared. If a better model becomes available somewhere else, switching should leave my research library and the reasons behind my decisions intact.

What I want an agent to leave behind

For any useful piece of work, I want to be able to answer:

• What was it trying to resolve? The question and why the action was needed.
• What did it use? Source references, versions, and inputs.
• What happened? Commands, results, failures, and changes.
• Can I continue? The files and tools needed to check the result or take the next step.

What feels like unlimited model thinking makes choosing the question more important. My review time is still limited. Instead of “research this topic,” I’d ask: find the assumptions behind this result, show me the relevant passages, and identify which ones our experiment doesn’t satisfy. That gives me something bounded to check and a decision to make. I can spend more model time on a difficult question without losing track of what the investigation is for.

How my setup works

I built several of these tools for myself because I kept repeating the same retrieval and reading tasks. The common requirement is simple: I should be able to use the same tool the agent uses.

Find a source and keep the reason for saving it

My heavily customised Firefox setup handles everyday browsing, with shortcuts for tabs, windows, and copying the current title and URL as a Markdown link. Bookmarklets connect it to my local tools:

• ResearchPocket captures links into a searchable library with notes and tags. “Compare this assumption with our baseline” is the part I want to remember. Its bookmarklet calls the installed CLI through a URL handler; no extension or background server is required. Sync is optional, and it stores links and bounded excerpts, so I keep papers separately.
• sioyek-arxiv downloads the PDF from an arXiv abstract or HTML page and opens it in Sioyek. The filename includes the title and version. The helper runs when invoked, and I can also call it from the terminal.

I contribute to Sioyek too; one merged change preserves autoscroll during smooth movement commands. These small reading interactions are worth fixing when I use them repeatedly. I maintain a Homebrew tap for sioyek-arxiv, amail, and supermoan so the tools are straightforward to install again. With Sioyek already installed:

brew install korigamik/tap/sioyek-arxiv
sioyek-arxiv setup --browser Firefox

Give the agent evidence it can bring back to me

• Local documents: LiteParse extracts text. My skill tells the agent to parse once, save the result, and search it for subsequent questions. Figures and equations still need the relevant page inspected.
• Web sources: Firecrawl CLI searches and fetches pages, with results saved to files. It uses a remote service; I choose it where that service helps.
• Web interfaces: The Chrome DevTools CLI lets the agent inspect the live page, requests, and console errors. I use the chrome-devtools-cli skill and the chrome-devtools command, without registering a DevTools MCP server in my agents. Firefox remains my everyday browser.

For a PDF with a text layer, the extraction step looks like this:

lit parse paper.pdf --format text --no-ocr -o /tmp/paper.txt
rg -n -C 4 "assumption" /tmp/paper.txt

The agent and I now have the same paper and a searchable intermediate file. I can open the cited passage in Sioyek, check the surrounding argument, and decide whether it applies. The extraction helps me find the evidence; it doesn’t establish that the claim is right.

For a live web interface, I can start with the same commands the agent uses:

chrome-devtools list_pages
chrome-devtools take_snapshot

The CLI starts its background daemon implicitly and keeps browser state across commands. Its package is still named chrome-devtools-mcp; removing the MCP entry from an agent’s configuration doesn’t mean uninstalling that package. It also doesn’t remove the need for a working browser connection. What I avoid is configuring another integration separately in OpenCode, Claude Code, and Codex when a shell command and an on-demand skill already do the job.

Recover earlier work without depending on one app’s memory

I built three CLIs for the places where useful context tends to get lost:

• trawl searches local coding-agent conversations and returns matching passages and a command to reopen the session. I can inspect the original transcript.
• amail searches Apple Mail’s local index and reads downloaded messages and attachments. Changes such as drafting or sending go through Mail.app.
• wa searches the WhatsApp desktop app’s local databases and retrieves surrounding context. It’s read-only, needs no second client pairing, and can only see what the app has downloaded.

Each has a skill explaining when to use it, how to narrow a query, and what the result can establish. Instructions load when needed; the CLI remains usable on its own. An empty search isn’t proof something never existed, and an old conversation isn’t proof its conclusion was correct.

Take the work with me

I use Tailscale to reach my agents when I’m away from my desk. Being able to take my work on the go matters to me. I don’t want to lose access to a useful workspace just because I’ve stepped away from the machine where it’s set up.

Local-first doesn’t have to mean desk-bound. Tailscale gives me a way to reach the machine where my agents and tools are already set up. I don’t have to recreate the environment somewhere else just to continue the work. The machine still needs to be awake and reachable; this isn’t a replacement for backups or a guarantee of access everywhere.

On my Android phone, I like using Xed-Editor. It makes working on the device feel much nicer, and I’m bullish on where it’s going. Having an editor I enjoy using on my phone, alongside access to my agents over Tailscale, makes taking the work with me feel practical.

That feels freeing to me. Not because I should work all the time, but because I get more choice about where and when I do. That’s what I want agents, and AI more generally, to do for us: give us more room to decide how we spend our time, rather than tie us more tightly to a screen.

Where MCP fits

I’m sceptical of API-gated MCP wrappers as the default for personal data that’s already available locally. Another service relaying my mail adds accounts, permissions, and failure modes. I want a concrete benefit for that overhead.

MCP supports local servers and progressive discovery.¹ It can work alongside skills; I don’t need to register every tool as an MCP server to make it useful to an agent. For Chrome DevTools, I’ve removed the MCP configuration and use the CLI with a skill instead. That gives me one interface I can run myself across agents, rather than another per-agent connection to maintain. This is a setup preference, not a claim that MCP itself requires a remote service or that a CLI fixes every browser problem.

The choice comes down to the job: local access where available, remote services where useful, and results I can inspect either way. Local retrieval also doesn’t make an interaction private from a hosted model if I send it the retrieved text.

The missing piece: a usable execution record

I have source references, saved files, commands, and Git history. I don’t yet have a complete audit trail connecting them. Next, I want:

• A record of each task: the stated reason for actions, tool and skill versions, inputs, results, changes, and failed attempts.
• References back to originals: enough to reproduce the work without duplicating private messages or credentials into a giant log.
• Useful setup checks: distinguish a missing executable from missing permissions or unavailable local data before an agent repeatedly retries.

Private database schemas still change, downloaded data can be incomplete, and skill instructions aren’t permission enforcement. Those are maintenance costs I have to own. The record should make failures easier to understand, and be readable in an ordinary editor by me or a fresh agent.

Make time to configure your tools

The exact tools here will change. The time I spend making repeated tasks easier, keeping evidence, and learning how the pieces work carries over when I replace one of them. I’d start small:

• Pick a task you repeat and notice where you keep intervening.
• Configure that part: a shortcut, a CLI command, or a skill with instructions you keep having to repeat.
• Use it on real work, then change it when something better comes along.

I want this setup to keep improving with the models. I also want to be able to return to the work, understand its state, and take the next step myself. That’s what makes the configuration time worthwhile.