> For the complete documentation index, see [llms.txt](https://docs.frends.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.frends.com/reference/administration/environments-and-agent-groups.md). # Environments & Agent Groups Manage the structure of your Frends deployment. Runtime execution and operational scoping in Frends rely on a hierarchical structure consisting of Environments, Agent Groups, and Agents. ## Hierarchy of execution architecture Frends decouples the centralized cloud management plane from the distributed execution plane using a three-tier operational model. At the highest level, a Tenant contains one or more Environments that establish logical and configuration boundaries. Within each Environment, one or more Agent Groups define execution clusters that share database state and message queues. Inside each Agent Group, individual Agents run as background services or container instances to perform the actual compute tasks and process data. ## Management The Administration section in the Frends Control Panel provides specialized management views corresponding to each level of the runtime hierarchy. ### Environments Environments provide logical isolation between different lifecycle stages, such as Development, Test, and Production. They act as scoping containers for Environment Variables, secrets, and deployment policies, ensuring that Process definitions remain consistent while runtime configurations adapt to each stage. In the Administration view, administrators can create new Environments, reorder their display sequence, assign visual color themes for clear identification across the platform, and delete empty Environments when they are retired. Learn more about Environment configuration and view settings in the [Environments reference documentation](/reference/administration/environments-and-agent-groups/environments.md). ### Agent Groups Agent Groups represent operational clusters of Agents working together to provide load balancing, high availability, and targeted execution. All Agents within the same Agent Group share a common message bus and database connection string, enabling seamless scaling and automatic failover. Agent Groups can be configured for specific operating environments, such as cloud containers, Linux hosts, or on-premises Windows servers, and can serve as dedicated API Gateways for incoming HTTP traffic. The management interface allows configuring database connections, message storage, cross-platform settings, and agent registration tokens. Learn more about Agent Group configuration in the [Agent Groups reference documentation](/reference/administration/environments-and-agent-groups/agent-groups.md). ### Agents and API Gateways Agents and API Gateways are the individual worker nodes and routing instances assigned to an Agent Group. Agents serve as full-featured compute nodes that listen to Triggers, execute sequential Tasks, and process data workflows. API Gateways operate as specialized reverse proxies and ingress endpoints, terminating TLS traffic, enforcing security policies, and routing external HTTP requests to internal services or backend Agents. The management views for both Agents and API Gateways share a common administrative layout, providing credential and port configuration, external address routing, real-time diagnostic event logs, and inspection of active Process Trigger endpoints. Learn more about provisioning and monitoring instances in the [Agents & API Gateways reference documentation](/reference/administration/environments-and-agent-groups/agents-and-api-gateways.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.frends.com/reference/administration/environments-and-agent-groups.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.