What does it mean to give a coding agent access to my accounts?

It means the agent runs on a machine where your credentials already live: your shell, your API keys, your config files, your logged-in browser profile. Instead of connecting to a product that asks you to import data, the agent reads what is already on the box and calls the same APIs you would call by hand.

Why do agent workflows get better over time?

Because every solved task leaves something behind on the machine. A script, a saved token, a note in the agent's memory file. The next task starts from that state instead of from zero. A workflow you built once by asking a question in plain English becomes a step the agent repeats without being asked.

Is it safe to let an agent create OAuth apps and hold my tokens?

It is the same risk as storing those tokens on your laptop, with one difference: the agent can act on them without you watching. Keep the agent on a machine you own, scope each OAuth client to the single API it needs, use separate credentials from your production ones, and read the sign-in screen before you approve it. Revoking a scoped client later takes one click.

Do I need MCP servers for this?

Not always. MCP is useful when a service has no CLI and you want a typed, reusable interface. For most tasks the agent will pick the shortest path it can already run: a CLI, a REST call with curl, or a small script it writes itself. Add an MCP server when you find yourself asking for the same integration repeatedly.

Can I trigger this from my phone?

Yes, if the agent lives on a machine that stays awake. You text or message the session, the agent works on the server, and the result lands in whatever service it has access to. Nothing runs on the phone, so closing the app does not stop the job.

What is the difference between agent memory and just a long chat?

A long chat is context that ends when the session ends. Memory is state that survives on disk: a memory file the agent reads on every run, scripts it wrote earlier, tokens it stored. That is why the second month of an agent workflow is faster than the first.

Give Your Coding Agent the Same Access You Have

TL;DR

The useful thing about a coding agent is not the model. It is what the agent can reach. An agent running on a machine that holds your keys, your files and your logged-in sessions can build workflows you never designed, because it can glue any two of your tools together on demand. Every solved task leaves a script or a token behind, so the next one starts further along. Integration-first products go the other way and ask you to import your data into them. Your data is already on your computer, and the agent knows how to find it.

A workflow that did not exist two days ago

Here is the exact sequence that prompted this post.

A message goes to the agent from a phone.
Opus starts generating a new version of a launch video.
The finished video appears in YouTube Studio, ready to preview.

Nobody built that pipeline. Two days earlier it did not exist. It started with one question typed into Claude Code: “can you figure out a way to upload the video we generated into YouTube?”

The agent worked it out on its own:

It found an unused Google API key already sitting in the environment.
It decided the cleanest route was a small custom client rather than a hosted tool.
It created an OAuth app under the same Google account and asked for a sign-in.
It wired the result into the existing video generation pipeline.

The part worth noticing came after. On a later run, with no instruction, the agent uploaded a newly generated video to YouTube so it could be previewed in place. The workflow had become a default.

Why the workflow compounds

Most people evaluate agents by asking what the model can do in one message. That is the wrong unit. The right unit is what the setup looks like after a month of use.

Every task an agent finishes on a machine you own leaves residue:

A script it wrote and saved.
A token it stored, so the next call needs no sign-in.
A line in its memory file describing how your setup works.
A CLI it installed.

None of that is a feature you configured. It is sediment. The second time you ask for something adjacent, the agent reads that sediment and skips the discovery work. Week four is quicker than week one, and the gap widens.

This is also why you do not have to design a memory system or a workflow engine. The file system is the memory system. The scripts are the workflow engine. Your job is to keep doing real work in one place and let the residue build up.

Integrations import your data. Agents already have it

Every SaaS product in this space has the same onboarding: connect your accounts, import your data, sit inside our walls. It made sense when software could only see what you handed it.

An agent inverts that. Your data is already on your computer or reachable from it. Your credentials are in your shell profile. Your repos are on disk. Your browser is logged in. A coding agent is the general-purpose glue between all of those, because it can read a file, call an API, write a script and run a command in one session.

That is the real point: not that the agent is smart, but that it stands in the one place where all your context already meets.

Two ways to connect your tools: the integration model imports your data into a product's walls, while the access model puts an agent on a machine where your keys, files and sessions already live

What “access” actually means

Access is not one switch. It is four separate things, and each one you grant makes the agent noticeably more capable.

Credentials. API keys, tokens and CLI logins already present in the environment. The YouTube story started with a key nobody remembered having.

The file system. Repos, exports, generated media, notes. The agent can read them without an upload step, and it can leave things behind for next time.

The network. Your internal services, your staging database, your private registry. This is where hosted agent clouds usually stop, because their sandbox is not on your network. Read where to run your coding agent for how the categories differ.

Identity. The ability to create an OAuth client, sign in as you, and act with your permissions. This is the strongest form and the one to grant most deliberately.

How to set this up

Step 1: put the agent somewhere that stays awake. A laptop that sleeps cannot own a workflow. A small server, a cloud box or a hosted sandbox all work. The guide for the manual route is running Claude Code on a VPS.

Step 2: do your real work there. The compounding only happens if the machine sees actual tasks. If the agent box is a clean room you visit occasionally, it stays empty.

Step 3: put credentials on the box, scoped. One file with the keys the agent may use. Keep production secrets separate from the ones you hand an agent, and prefer a scoped token over an account-wide one.

Step 4: let it solve access problems itself. Instead of researching an API, ask for the outcome. “Upload this to YouTube” is a better prompt than “write a Python script using the YouTube Data API v3”. The agent will pick the shortest path it can actually run, which is often not the one you would have chosen.

Step 5: keep a memory file. A single Markdown file the agent reads on every run, describing your setup, your hosts and your conventions. Every time it learns something durable, have it write the line.

Step 6: add MCP servers only where they earn it. When you keep asking for the same integration, make it a real interface. The MCP servers guide covers the shape, and Claude Code with the omg.dev MCP shows one wired end to end.

The guardrails worth keeping

None of this argues for handing an agent everything at once.

Own the machine. If a vendor can switch it off, the sediment is theirs, not yours.
Scope every OAuth client. One client per API, created for the task. Revoking a narrow client costs nothing.
Read the consent screen. The agent asking you to sign in is the one moment you get to check what it is requesting.
Separate the money. Billing credentials, domain registrars and payment dashboards deserve a deliberate decision, not a default.
Keep the work in version control. The scripts an agent leaves behind are code. Review them the way you review code.

Why this changes what to build

You will probably not train a foundation model. You can absolutely build the context pipeline around one, and that is where the difference between two people using the same model shows up.

The model is a commodity that improves for everybody at the same time. Your accumulated access is not. It is specific to you, it grows every week you use it, and nobody can copy it.

This is the thinking behind omg.dev: a cloud personal computer for your agents. A machine that stays awake, holds your context, and can be reached from your phone, so the workflows you accidentally invent on a Tuesday are still running in a month.