PROMPT.md becomes the agent’s system prompt, and an optional guild.yaml declares the integrations, sub-agents, and built-in tools it may call. There is no TypeScript, no build step to compile, and no container — Guild runs the agentic loop itself.
Use this agent type when the work is expressible as instructions plus tools. It is the shortest path from an idea to a running agent, and it is the type to reach for first.
Because the loop runs inside Guild, a Native agent also starts faster than the container-backed types. Goose and OpenClaw agents each get their own container, created when the task starts and destroyed when it ends; a Native agent has nothing to start, so its first turn begins as soon as the task is dispatched.
Native agents take text in and return text out. When you need attachments, a custom input schema, per-agent model preferences, or credential requests, build a TypeScript LLM agent. For a structured output schema, use a Goose agent or auto-managed state agent. See What Native agents do not do.
Create a Native agent
- CLI
- Web
PROMPT.md with your agent’s instructions, then save and run the agent like you would any other Guild agent.The prompt
PROMPT.md is the whole agent. Its contents become the system prompt, and it is the only required file — a missing or empty PROMPT.md fails the build before any tool validation runs.
PROMPT.md therefore applies to tasks created after the next build, not to a session already in flight.
Workspace variables
A prompt can reference a workspace variable with{{env.KEY}}, and Guild substitutes the workspace’s value when the task runs. Keys must match [A-Z][A-Z0-9_]*; a malformed reference is a build error, so a typo surfaces at save time rather than as a literal {{env.…}} in the model’s context.
Tools (guild.yaml)
Every tool a Native agent can call is declared in guild.yaml at the root of the agent’s version files. Each integration operation, sub-agent, and built-in you declare becomes a tool the model sees. Omit the file when the agent needs no tools at all.
integrations, sub_agents, and builtins are the same as for Goose agents — see Integrations and sub-agents.
Built-in tools
A Native agent runs in Guild’s own loop rather than a container, so the built-ins available to it differ from the container-backed types:ui_progress is specific to Native agents. The console and guild services — and so console_log and guild_credentials_request — are not available; declaring either is a build error. A missing credential surfaces to the model as a tool error it can explain, rather than as a request to connect the integration.
The
environment field is not supported for Native agents. There is no container to pin an image to.Input and output
Native agents have a fixed text contract: they take text in and return text out. Unlike a Goose recipe, there are no declared parameters and no response JSON schema — the input and output schemas are applied for you at build time. Follow-up messages continue the same task with the transcript intact, so a Native agent holds an open-ended session without any extra declaration. Workspace context is injected into the first user message of a session only.Build-time validation
Guild validates the agent when you save a version:- Validate PROMPT.md — the prompt is present and non-empty, and every
{{env.KEY}}reference is well formed. The fixed text input/output contract is applied here. - Validate Guild integrations — each integration in
guild.yamlresolves to a published version, and any listed tools map to real operations on it. - Validate Guild subagents — each sub-agent resolves to a published version.
- Validate Guild builtins — each service and tool is one a Native agent may use.
- Store Guild tools — the resolved tool manifest is recorded on the version.