Integrate Existing Agents

You can use an existing agent in NeMo Gym, integrate an external one, or build your own from scratch.

SimpleAgent is a native NeMo Gym agent that handles general-purpose multi-step tool calling with configurable max steps, and works with any Resources server out of the box. NeMo Gym also includes agents that integrate external tools: for example, MiniSWEAgent wraps an external coding harness running in Docker containers and converts its output back into the NeMo Gym format, and claude_code_agent runs the Claude Code CLI. Because every Gym model server speaks Anthropic Messages, you can point Claude Code at any backend — see Anthropic Messages.

Agent session hooks

For Environment Server execution, implement these SimpleResponsesAPIAgent hooks:

• _seed_agent_session_state(body): validate grants, initialize the harness, and return an AgentSessionState. If setup fails and cleanup cannot finish, raise AgentSessionSetupError(state, error=original_error) so close can retry cleanup.
• _close_agent_session_state(state): stop the harness and its tools, then return an AgentCloseSessionResponse with observations. Raise if cleanup is not confirmed.

The base handles seed retries and close receipts. In responses(), use _require_agent_session() to reject incomplete or closing sessions before execution. A borrowed task sandbox remains owned by the Resources Server: disconnect from it after stopping the harness; do not destroy it. Verification starts only after agent close succeeds.

When using the shared process supervisor, confirm its cleanup receipt before cancelling the provider’s exec request. Cancellation can kill the provider’s entire process group, including the supervisor when it is already the group leader (as with the local provider). setsid() alone does not guarantee cleanup; the close ordering does.

Tools in Agent vs. Resources Server

Existing agents may come with predefined tools, allowing you to leverage them directly and use the Resources server to supplement with any additional external tools. When building a new environment, prefer defining tools in the Resources server rather than the Agent server. This separation of concerns allows different agents to share the same Resources server without duplicating tool logic.