How your agent works
Worth ten minutes before you start delegating real work. Knowing where your agent runs and what it remembers is the difference between prompts that land and prompts that quietly do nothing.
Where it runs
Your agent is not a shared service. Provisioning creates a dedicated EC2 instance in our AWS account that belongs to your tenant alone, with its own IAM role, its own encrypted secret, and its own storage. Two customers running an agent called “Gina” get two entirely separate machines.
The instance runs a small always-on service that listens to Slack over Socket Mode. When you message the agent, that service starts a fresh container for the task and runs Claude Code inside it, authenticated with your own token.
What happens when you send a message
- The agent checks that you are on its allowlist. Messages from anyone else are ignored.
- A container starts with your credentials injected as environment variables — Claude token, and any GitHub or AWS credentials you supplied.
- The agent works: reading, writing files, running commands, calling AWS or GitHub. It reports progress in the Slack thread.
- The container exits. Its filesystem is discarded except for the workspace and memory described below.
Replying in the same Slack thread continues the same session, so the agent still has the context of what it just did. Starting a new thread starts fresh.
What it remembers
| Layer | Holds | Lasts |
|---|---|---|
| Thread | The conversation you are in | While the thread is active |
| Workspace | Files and repositories it is working on | Across tasks |
| Memory | Facts, decisions and preferences it has recorded | Long-term |
Memory is not automatic transcription — the agent records what looks worth keeping. If something matters, say so plainly: “remember that we deploy on Thursdays, never Fridays.”
What it cannot do
Stated plainly, because discovering these mid-task is frustrating.
- It cannot exceed its credentials. No AWS keys means no AWS work. A read-only key means it can diagnose but not fix. When it hits a permissions wall it will tell you which action was denied.
- It cannot see your screen, inbox, or private systems unless you have connected them. It knows what is in Slack, its workspace, and whatever its credentials reach.
- It has a finite working context. A very long task will not hold every detail from the beginning. Break large work into stages with checkpoints rather than one enormous instruction.
- It cannot act while you are away unless scheduled. Agents respond to messages and to schedules you create. There is no background initiative beyond that.
- It is not a database. Memory is for durable facts and decisions, not for storing records you need to query reliably.
- It can be wrong. It writes real code and touches real infrastructure. Treat its output the way you would a capable new colleague's: review before it reaches production.
Agents, credits, and limits
Each agent you run consumes one credit. Your credit balance is what allows you to provision — you can see it, and how many you have deployed, in the console. Deleting an agent releases its credit and destroys its instance, secret, and storage. That is not reversible, so export anything you want to keep first.
One agent can do many things. Run several when you want genuinely separate identities — a different Slack presence, a different credential set, or a different workspace — not merely to run two tasks at once.
Next: Getting good results · Agent profiles · Security