In Dude, Just Download OpenCode, I wrote about the boring stack: Linux Mint, OpenCode, OpenRouter. That post was about setting yourself up. This one is about the trick I actually care about: taking that setup and connecting it to someone else's work.
When a client or collaborator needs to touch my systems, onboarding can turn into a VPN login, a wiki page, and a tour of the password manager. I have started doing something different. I give them an agent configured for the job.
The Workflow
A new person shows up. I set up their agent when they need it. That is the just-in-time part.
- Install OpenCode. One command. The previous post has the setup.
- Connect the tools for their work. I choose which services they need and arrange their access. MCP, short for Model Context Protocol, is the connection that lets the agent use those tools.
- They connect their own OpenRouter account. They enter their API key on their machine and choose a model.
Then we try a small task together. Can it find the right project? Read the information they need? Explain what it would do next?
The install is the onboarding. The first session ends with them doing something useful with my systems. The services and permissions still need preparation on my side; a quick setup for them depends on that work already being done.
Why This Is Flexible
The tools fit the job. A collaborator reviewing a project might only need to read its notes and check its status. Someone maintaining it needs a different set of actions. I can keep the same agent and change the connections and permissions.
The model bill is theirs. Their OpenRouter account pays for their model usage. I do not need to collect their key or split a shared model bill. We still agree on which providers may receive the project's information, and they should set a spending limit.
The pattern travels. A client, a friend, a workshop, a contract gig. The setup stays familiar. The tools and access change with the work.
This is the practical side of my "just use MCP" post: use the connection that already exists, then spend your effort deciding what the person actually needs to do.
The Honest Part
Their model account, my systems. If the agent makes a mistake, their bill is not the only thing at stake. It could change my files or affect a running service.
So I start with read-only access where that is enough. Permission to make changes needs a clear job and clear limits. Being able to ask for an action does not mean the service should allow it.
Choosing the MCP connections is only part of this. The services behind them must enforce the person's permissions. An agent can also have local file and terminal access, so its account and environment matter too.
And ending access means revoking it at the service. Removing a connection from a configuration file is housekeeping; it does not invalidate a credential someone still holds or erase information they already received.
How This Actually Works
I keep three decisions separate: who pays for the model, what the connected services allow, and when private project files are available.
The OpenRouter key handles the first. It does not grant access to my systems. The connected services need their own authorization. The MCP authorization specification describes how protected HTTP services check access tokens and permissions; simply speaking MCP does not automatically provide that protection.
For private project files, my working vaults add an approval step. An authorized person supplies a second-factor code to open the vault through its supported workflow. After that, permitted programs can use the files during the open session. It is not a fresh approval for every agent action, and it does not cover every connected service. The server administrator still controls the underlying machine and vault keys.
My OpenClaw proxy post covers another piece: keeping service credentials behind a small service instead of handing them to the agent. That limits which credentials the agent can read, but the service still has to check what it lets the agent do.
Why I Like It
I want someone to leave the first session able to act. They should be able to ask about the project, inspect the relevant work, and take an agreed next step without first learning how I arranged every system.
The harness is the asset; the model is a config value. The harness is the software around the model that holds the conversation and uses the tools. Keeping that setup familiar makes it easier to change models or connect a different project.
If you work with me, this is probably how you will meet my systems: an agent with the right connections, enough context to get started, and access chosen for the work we are doing together.
Photo by Franck V. on Unsplash.
Content on this blog was created using human and AI-assisted workflows described in my standards and workflow posts. Original ideas and editorial decisions by Justin Quaintance.