An agent's environment is everything it can touch when it acts: the working directory, the files in it, the shell it runs commands in, the environment variables, and whatever network access it has. If the model is the brain, the environment is the room it is standing in. It defines the boundary of what the agent can actually do, no matter how capable the model is.
Tools are only as good as the environment
A tool is a door, but the environment decides what is on the other side. A "run command" tool is powerful in a repo with the right dependencies installed and useless in an empty box. Give an agent the same task in two environments and you can get wildly different results, because one has the test runner, the API keys, and the source tree, and the other does not.
What the environment typically includes:
- The filesystem the agent can read and write.
- The shell and installed tools it can invoke.
- Environment variables and credentials it inherits.
- Network reach, if any.
Why it is worth being deliberate about
Setting up the environment well is half of getting good agent output. The other half is limiting it. You want the agent to have what it needs to do the job and nothing it could use to do damage, which is exactly what a sandbox gives you: a controlled environment where a mistake stays contained.
Related terms
Filesystem
The filesystem is the set of files an agent can read and write. It is its main source of truth and its main way to make durable changes.
Read definition →Sandbox
A sandbox is an isolated environment that limits what an agent can touch, such as the filesystem and network, so a mistake stays contained and cannot damage the real system.
Read definition →Tool
A tool is a named action, with a typed input schema, that a model is allowed to call. Tools are how a model that can only produce text gets to actually do things: read a file, run a command, search the web.
Read definition →