Setting up accounts for your agents
· Avi Agola, The Seattle Compute Company
Smith agents do work behind a login, so before an agent can research a gated source, it needs an account to sign in with. This guide covers which account to use for which site, how to get it set up, and how to stay in control once the agent is using it.
For the reasoning behind the two identity models, read Delegated vs. agent-owned identity. This guide is the practical version.
Step 1: List the sites the work needs
Before setting anything up, write down where the answers live for the tasks you want to hand off. For most teams it's a short list:
- A professional network (LinkedIn)
- A data source (Crunchbase, PitchBook, a research database)
- A code host (GitHub)
- An institutional portal (a university library, a grants database)
- Internal tools your team already logs into
Step 2: Pick an identity for each site
Ask one question per site: is the account itself the asset, or is any seat good enough?
| If the site is… | Use | Why |
|---|---|---|
| Your professional profile, where your network, history and credibility do the work | Delegated (your account) | A fresh account has no connections and no trust. The work only happens as you. |
| A membership only you hold | Delegated | There's no other seat to give it. |
| A data tool or research portal where any paid seat sees the same data | Agent-owned | You get a clean record of what the agent did, separate from you. |
| A code host or shared tool where you need to know who changed what | Agent-owned | Attribution is the point. Revoking it never touches your access. |
A quick rule: reading usually works with an agent-owned account. Acting with your reputation (connecting, messaging, posting as you) usually needs delegated.
You can mix both for one agent. A recruiting agent might read Crunchbase on its own seat and send LinkedIn connects from yours.
Step 3: Set up the account
For a delegated account: connect your login for that site to the agent. Your credentials go into an encrypted vault. When the agent reaches that site's sign-in page, the vault fills it in. The agent never sees your password.
For an agent-owned account: give the agent its own seat on the service, using the agent's own email address. Every Smith agent has one, so verification emails and password resets go to the agent rather than to your inbox. Its credentials go in the same vault.
Either way, check the site's terms on seats and automated access before you start, especially for paid data tools.
Step 4: Get through the first sign-in
The first login on a new site is where people most often need to step in. Expect it on sites with:
- Two-factor codes sent to your phone or authenticator
- "New device" checks or email confirmations
- CAPTCHAs or other bot checks
When this happens, the agent stops and tells you in the thread. Take over its live screen, complete the step yourself, and hand it back. After the first successful sign-in, most sites remember the session and later runs go through on their own.
Give the agent a small test task right after setup, like "sign in to Crunchbase and tell me the last round for Stripe." It's a cheap way to find login problems before a real task depends on them.
Step 5: Set limits on anything that acts as you
For delegated accounts that can send messages or take actions, decide the limits up front and write them into the agent's role, so they apply to every task without you repeating them:
- How many messages or connection requests per day
- Whether it should send, or draft and wait for your approval
- Which actions are off-limits entirely
Platforms like LinkedIn restrict accounts that send too many requests too quickly, and it's your account that takes the hit. Start low and raise the limit once you've reviewed a few runs.
Step 6: Match accounts to roles across a team
When several agents work together, give each one only the accounts its role needs (see Building an agent team):
- One agent per sending account. If an agent can send from your LinkedIn or email, it should be the only one that can. Other agents that need the same site get read-only access, written into their roles.
- Separate agent-owned accounts per agent. Two agents shouldn't share one GitHub or Crunchbase login, or the trace can't tell them apart.
- Write the accounts into each role. List every account the agent has, and what it may do with each: "LinkedIn: Avi's account, read-only."
Staying in control
- See what happened. Every action is recorded against the agent that took it and the account it used. If a result looks wrong, the trace shows each step.
- Stop an agent at any time, mid-task.
- Take over the screen whenever a step needs a person.
- Revoke access. For a delegated account, disconnect it from the agent. For an agent-owned account, delete the agent's account. Neither touches your other logins.
Checklist
- [ ] Listed every site the work needs
- [ ] Picked delegated or agent-owned for each, and why
- [ ] Connected or created each account
- [ ] Ran a test sign-in and handled any two-factor or device checks
- [ ] Set limits for anything that acts from your account, in the agent's role
- [ ] Only one agent can send from each of your accounts
Next
Email acme@agents.seattlecompute.com and an agent writes back.