What does a first agent setup actually need?
You need an agent application, a defined project folder, permission rules, a spending limit and a useful task. Start with a draft you can review, such as a summary of approved documents. Expand only after you understand what the software is doing.
- One host, on one machine you control
- One workspace directory, credential files denied by rule
- A deny list written before the first prompt
- A spend ceiling that starts at zero
- Three workflows that produce a draft, not an action
- A review step before anything leaves your machine
Which host should you install first?
Choose one host, meaning the application that runs the agent and connects its tools. Learn its settings and review process before comparing several at once.
Base the choice on the task. Coding work needs file editing and tests. Reporting may need approved documents and a spreadsheet tool. Confirm those requirements before choosing the application.
| Check | What good looks like | What failure looks like |
|---|---|---|
| Skill location | You can list the directory and see it | The agent never mentions a skill you added |
| Permission source | Each rule names the file it loaded from | Approvals pile into a file nobody reads |
| Spend visibility | A usage command reports the session total | The invoice is the first signal |
| Stop control | One key interrupts a run in progress | Your stop button is closing the window |
| Removal path | Documented uninstall, credentials revoked | Unconfirmed until you test it yourself |
How do you bound the workspace before the first run?
Use a dedicated project folder and keep account credentials out of it. Permission settings should limit what the agent can read or change. Written instructions explain what you want, while software-enforced rules provide a separate control.
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./**/secrets/**)"
],
"ask": [
"Bash(git push *)",
"Bash(rm *)",
"Bash(curl *)"
],
"allow": [
"Bash(npm run lint)",
"Bash(npm run test *)"
]
}
}Three properties are worth memorizing. Deny beats allow, so a deny rule cannot be talked out of the way by a persuasive prompt. Allow rules in a shared project file wait for the workspace trust dialog, while deny and ask rules take effect immediately, which is the asymmetry you want. And a key set in several files resolves by precedence, managed organization settings on top, your personal file at the bottom.
Check the active rules and where they came from. A setting written in a file may not be the setting your application actually loaded.
# Where skills and settings live on disk
ls ~/.claude/skills # personal skills, every project
ls .claude/skills # project skills, this repo only
cat .claude/settings.json # shared, committed to the repo
cat .claude/settings.local.json # personal, kept out of git
ls ~/.hermes/skills # the Hermes skills directory
# Inside a running session
/permissions # every rule, and the file it came from
/status # which settings sources actually loaded
/usage # session cost and what consumed it
/context # what is filling the context windowWhich actions stay behind a human?
Decide which information the agent may read and where it may save drafts. Require review for actions such as sending messages, changing important records or publishing pages.
| Action | Posture for month one | Failure the gate prevents |
|---|---|---|
| Send | Draft only, a person sends | An unfinished reply in a client inbox |
| Publish | Preview only, a person merges | A wrong price live on a public page |
| Spend | No billable key installed | A retry loop billing overnight |
| Delete | Never, in any form, month one | A file that was the only copy |
| Deploy | A person runs the deploy | A broken build promoted to production |
| Credentials | Stored by the host, never in chat | A live key kept in a transcript |
What should the first month cost?
Check what your existing subscription includes before adding usage-billed services. If a separate API connection is needed, agree on a budget and spending alerts first.
Start a fresh conversation for unrelated work and choose a model suited to the task. Longer conversations and multiple agents can increase usage. Check actual account reports rather than assuming a fixed cost multiplier.
Which three workflows go first?
Choose a result you can inspect: a research brief with sources, a weekly summary or a proposal outline. Write down the inputs, expected output and review checks before the first run.
Run the task successfully more than once before scheduling it. Include missing or incorrect input in the trial. A scheduled job also needs a way to stop, report failures and request approval when necessary.
How long should a first agent setup take?
Allow time for installation, permissions and testing. The duration depends on your computer and tools. A successful install is only the first step; review several trial outputs before relying on the process.
Do I need to write code to set up an agent?
Some products have a visual setup, while others require settings files or commands. You may want technical help with connections and permissions. You should still understand the task and how its results will be checked.
What is the first thing to check when an agent does something unexpected?
Inspect the actual files and activity, then check the loaded permission rules and instructions. Confirm whether the action was allowed and whether an expected approval step was present.
Turn this checklist into your working setup
Use this checklist to define the workspace boundary, approval rules, cost ceiling, and first workflow. Bring those decisions to a call if you want help testing the setup against your actual business tasks.