# Architecture examples

## Foundry worker with direct connection policies

Foundry worker with direct connection policies, which can also be referred to as a "direct connection", is the recommended default for accessing external systems that accept inbound traffic from Foundry, such as REST APIs and cloud/SaaS systems.

In this scenario, data connections run in an isolated compute container called a [Foundry worker](../core-concepts/index.md#foundry-worker), which handles authenticated encrypted network requests.
The external system must accept inbound traffic from Foundry. Network egress from Foundry is managed and administered in-platform via [direct connection egress policies](../../administration/configure-egress/index.md#direct-connection-egress-policies).

External system credentials are stored with AES-256-GCM server-side encryption and can only be decrypted by containers triggered by authorized users.

To create a direct connection, follow instructions about [setting up a source](../set-up-source/index.md).

![Architecture diagram of direct connection.](../../../assets/9d06397570b6b53bb57b01bbb7256f56c450f081913ef6b59299c22067780474.webp)

## Foundry worker with agent proxy policy

Foundry worker with agent proxy policies, which can also be referred to as an "agent proxy" or an "agent thin mode" connection, is the recommended architecture to access external systems hosted on private networks. It requires the use of a [data connection agent](../core-concepts/index.md#agents).

In this scenario, the agent acts as a simple network tunnel without performing any data processing itself.

The agent initiates a network request with Foundry to establish a websocket connection. [Learn more about network controls available on agents.](../agent-proxy/index.md#security-controls-specific-to-agent-proxy)

All data connection and computation capabilities are executed by a [Foundry worker](../core-concepts/index.md#foundry-worker), an isolated container with scalable compute resources that processes data and communicates with external systems via the provided websocket.

The ability to use the agent as a proxy is granularly managed and administered in-platform via [agent proxy egress policies](../../administration/configure-egress/index.md#agent-proxy-egress-policies).

Multiple agents can be used to load balance workloads across multiple external systems.

Like [direct connections](#foundry-worker-with-direct-connection-policies), external system credentials are stored using AES-256-GCM server-side encryption and can only be decrypted by the container triggered by authorized users.

To create an agent-proxy connection, you will need to:

* [Set up an agent.](../set-up-agent/index.md)
* Create one or many [agent proxy policies](../../administration/configure-egress/index.md#agent-proxy-egress-policies).
* [Set up a Foundry worker source](../set-up-direct-connection/index.md) using the policies above.

![Architecture diagram of agent proxy connection.](../../../assets/928763f2c5c53eaf9705c967b00429610000ae784ab073f1905e6446360b2a91.webp)

## Legacy architecture: Agent worker

:::callout{theme="warning" title="Legacy"}
Agent worker is in the [legacy](../../platform-overview/development-life-cycle/index.md) phase of development. We recommend [Foundry worker with agent proxy](#foundry-worker-with-agent-proxy-policy) for on-premise and privately hosted systems. See [Foundry worker vs. agent worker](../foundry-worker-vs-agent-worker/index.md) for the comparison.
:::

Agent worker connection, which can also be referred to as "agent thick mode", is the historical architecture used to access external systems hosted on private networks from Foundry. It requires the use of a [data connection agent](../core-concepts/index.md#agents). [Learn more about agent worker known limitations.](../agent-worker/index.md#known-limitations)

To migrate an existing agent worker source to a Foundry worker, follow the [migration guide](../foundry-worker-vs-agent-worker/index.md#switch-source-from-agent-worker-to-foundry-worker).

In this scenario, the agent constantly polls Foundry via unidirectional outbound connections secured by HTTPS for new tasks to execute. Once received, the task is executed by the agent itself, also called [agent worker](../core-concepts/index.md#agent-worker) and results are sent to Foundry over that same unidirectional connection. All the networking configuration required for the agent to be able to communicate with internal source systems is [configured on the agent host itself](../set-up-agent/index.md#configure-agent-network-access).

External system credentials are stored on the platform using AES-128-GCM encryption with keys stored on the agent. During capability execution, the agent retrieves encrypted credentials from Foundry, decrypts them locally, and uses them for queries. Decrypted credentials are automatically deleted from memory after execution.

To create an agent worker connection, you will need to:

* [Set up an agent.](../set-up-agent/index.md)
* Configure it to be an [agent worker](../agent-worker/index.md).
* [Set up an agent worker source](../set-up-source/index.md) and assign it that agent.

![Architecture diagram of agent worker.](../../../assets/81f83e5b0d1bacde4eed3d403f1cb760803775ac56e1e205fccfb9566132a66c.webp)

## Summary

| Type of connection | Capability execution | Networking | System credentials |
| :--: | :--: | :--: | :--: |
| [Direct connection](#foundry-worker-with-direct-connection-policies)| In Foundry | Direct from Foundry to source systems. | Stored encrypted in platform with encryption keys in platform. |
| [Agent proxy](#foundry-worker-with-agent-proxy-policy) | In Foundry | Outbound connection from agent to Foundry to establish a websocket and proxy traffic. | Stored encrypted in platform with encryption keys in platform. |
| [Agent worker (legacy)](#legacy-architecture-agent-worker) | On agent host | Outbound connection from agent to Foundry to poll tasks. Inbound connection from agent to source systems. | Stored encrypted in platform with encryption keys on agent. |