Agyn: Scalable AI Agent Platform

• Agyn is an open-source platform for operating AI agents at scale, defined by its agent-agnostic, model-agnostic, and cloud-agnostic design.
• It features a signal-driven, stateful serverless runtime on Kubernetes that preserves conversational continuity and efficiently handles bursty, short-lived workloads.
• The platform integrates agent definition as code via Terraform and employs a multi-layered zero-trust security architecture to ensure credential isolation and secure agent interactions.

Agyn is an open-source platform for operating AI agents in production at organizational scale. It is designed around three principles tailored to agent workloads: a signal-driven, stateful serverless runtime on Kubernetes; a Terraform provider for agent and harness definition; and a security model grounded in zero-trust and least-privilege principles. The platform is described as agent-agnostic, model-agnostic, and cloud-agnostic, and it is positioned as infrastructure for reliably running many agent instances with governance, isolation, and elastic compute rather than as a framework for building a single agent (Benkovich et al., 26 May 2026).

1. Problem formulation and scope

The motivating claim behind Agyn is that production agent workloads differ materially from conventional serverless applications. In the formulation given for the platform, the trigger is usually a conversational message rather than an HTTP request; the unit of work can last minutes rather than milliseconds; state must survive across multiple spawns; each agent instance may require access to internal enterprise systems; and each instance should be isolated per user or task (Benkovich et al., 26 May 2026).

Agyn is intended to address three deployment problems jointly. The first is efficient on-demand execution for workloads that are bursty, user-driven, and short-lived. The second is agent definition as code, so prompts, tools, secrets, policies, and resource limits can be versioned, reviewed, and rolled back like infrastructure. The third is zero-trust access, so agents can use internal services without exposing credentials to the model or trusting the runtime by default (Benkovich et al., 26 May 2026).

This scope distinguishes the platform from a purely model-centric or framework-centric conception of agents. Agyn is characterized as agent-agnostic because it can run agents built with different frameworks; model-agnostic because it does not depend on one LLM vendor or one model family; and cloud-agnostic because it is deployable on any Kubernetes cluster rather than being tied to a single cloud provider (Benkovich et al., 26 May 2026). A common misconception is therefore to treat Agyn as a specific agent library or orchestration DSL; the paper instead presents it as an operational substrate for heterogeneous agents.

2. Signal-driven, stateful serverless runtime

The central runtime abstraction is that each agent instance is ephemeral compute with durable state. An instance starts only when needed, runs while active, and is reclaimed when idle, while persistent state remains available for later activation (Benkovich et al., 26 May 2026). The runtime is explicitly designed for conversational, event-driven agents rather than ordinary HTTP serverless functions.

The workflow is specified as follows. An external client sends a message through web chat, an API, or a custom connector such as Slack or Teams. The Notifications service publishes an event. The Agents Orchestrator subscribes to that event and decides which agent instance should handle the thread. The orchestrator then resolves secrets, requests an OpenZiti identity, and instructs the k8s-runner to create a Kubernetes pod. The pod starts with the agent container, the thread context, and the persistent volume for workspace and state, allowing the agent to resume from prior context rather than starting fresh (Benkovich et al., 26 May 2026).

Idle reclamation is a defining part of the runtime semantics. While active, the agent sends keep-alives every 10 seconds. If the idle timeout elapses, with a default of 5 minutes, the orchestrator stops the pod and deletes its network identity. The persistent volume and thread history remain, and a later message creates a fresh pod that reattaches the same state (Benkovich et al., 26 May 2026).

The architectural significance of this design lies in the combination of elasticity and conversational continuity. Standard FaaS systems are described as suitable for stateless HTTP workloads but not as a natural fit for conversational, stateful agent execution (Benkovich et al., 26 May 2026). This suggests that Agyn’s runtime is not merely a repackaging of generic serverless primitives, but a specialized execution model centered on thread reactivation and state persistence across cold starts.

3. Agent definition and harness as code

Agyn exposes the entire agent definition and its harness via a Terraform provider. The defined surface includes prompt or system prompt, tools, secrets, resource bounds, model choice, agent container, workspace configuration, MCP servers, persistent volumes, network identity, and other operational policies (Benkovich et al., 26 May 2026). The term harness denotes the surrounding infrastructure that is reattached every time the agent spawns.

The stated rationale for using Terraform is operational rather than merely ergonomic. The platform associates Terraform with version control, peer review, rollback, reproducibility, and reusable modules for common patterns (Benkovich et al., 26 May 2026). Production-agent configuration is therefore treated as an operational decision with governance and security implications, not as an implementation detail buried inside application code.

The update flow is declarative. On terraform apply, definitions are resolved through the Gateway and stored or applied in the Agents Service. Subsequent messages then spawn pods using the updated definition, and no platform restart is required for the new configuration to take effect (Benkovich et al., 26 May 2026). The paper further notes that organizations can package common agent harnesses as reusable Terraform modules, including an MCP server plus its secrets, a standard workspace layout, or a standard resource policy (Benkovich et al., 26 May 2026).

A common misunderstanding is to interpret “agent-as-code” as referring only to prompts or tool declarations. In Agyn, the term is broader: it encompasses the execution envelope, identity surface, persistent state attachments, and policy controls that surround the agent process itself. This broader formulation is integral to the paper’s governance argument.

4. Security architecture: zero trust, least privilege, and authorization layers

Agyn assumes that the model and the agent are not trustworthy by default, even when running inside the cluster (Benkovich et al., 26 May 2026). The security architecture is therefore designed to avoid exposing credentials to the LLM and to authorize access individually rather than relying on ambient trust.

The first mechanism is per-container isolation. Each agent pod is split into separate containers: the main container runs the agent process, while sidecar containers host MCP servers. Each container has its own filesystem and process tree, with only the loopback interface shared locally. Secrets are injected only into the container that needs them, usually the MCP sidecar, and are never injected into the agent container that drives the LLM (Benkovich et al., 26 May 2026). The paper explicitly frames this as a defense against indirect prompt injection and model misuse of credentials.

The second mechanism is zero-trust overlay networking with OpenZiti. At spawn time, each agent receives its own x509 identity. Identity is established during the mTLS handshake before application code runs, and the Gateway extracts the identity and propagates it through the call chain. Downstream services can therefore determine exactly which agent is making a request. Access control is enforced with ABAC policies so that each agent can reach only the services it is explicitly allowed to reach, with no implicit trust based solely on network location (Benkovich et al., 26 May 2026).

The third mechanism is relationship-based authorization with OpenFGA. This layer controls who can configure an agent, who can interact with an agent, and which users are participants in a thread. The paper mentions roles including owner, maintainer, and participant (Benkovich et al., 26 May 2026). In effect, the network layer establishes authenticated agent identity, while the authorization layer governs organizational and thread-level permissions.

Taken together, these mechanisms define a multi-layered security model: process and filesystem separation inside the pod, identity-based connectivity across the network, and relationship-based governance above both. A plausible implication is that Agyn treats security not as a boundary around a cluster, but as a composition of workload identity, explicit policy, and secret minimization.

5. Architecture and operational model

The platform architecture is organized around external clients, a Gateway, a control plane, a data plane, a Notifications service, an Agents Orchestrator, a k8s-runner, persistent volumes, and an OpenZiti overlay network (Benkovich et al., 26 May 2026). External clients include web chat, console, and custom connectors. The Gateway is the entry point that mediates requests. The control plane manages agent definitions, orchestration, and tenant state, while the data plane handles runtime events and agent pod lifecycle (Benkovich et al., 26 May 2026).

Interaction is organized around threads. Starting a new thread with an agent spawns a dedicated instance for a specific user and task, and agents can also spawn threads with other agents, which supports multi-agent collaboration (Benkovich et al., 26 May 2026). This thread-based execution model is central to how Agyn unifies conversational state, identity, and runtime scheduling.

The platform also includes an administrative and governance interface through the web console. The console provides organization configuration, access management, secret management, and usage observability (Benkovich et al., 26 May 2026). Agyn is therefore not only an execution substrate but also an administrative surface for policy and operations.

The implementation section adds several concrete system choices. Platform services are written in Go. PostgreSQL serves as the durable store, and Redis is used for pub/sub fan-out. OpenZiti is embedded through the Go SDK in infrastructure services to avoid sidecar conflicts, while agent pods use a Ziti TPROXY sidecar for transparent overlay access. The identity lifecycle includes ephemeral per-workload agent identities created at spawn and deleted on stop, ephemeral per-pod service identities with leases, and persistent runner, app, or device identities provisioned by service token. A Ziti Management service handles controller API calls and lease-based garbage collection. Deployment is packaged as a Helm chart, is deployable on any Kubernetes cluster, and includes a bootstrap repo for one-command setup (Benkovich et al., 26 May 2026).

6. Evaluation, comparative positioning, and limitations

The paper does not report benchmark numbers such as latency, throughput, or cost curves. Its evaluation is primarily a feature comparison against AWS Bedrock AgentCore, Anthropic Claude Code (cloud), Google AX, and kagent (Benkovich et al., 26 May 2026). According to that comparison, Agyn is claimed to be the only surveyed platform that simultaneously offers self-hosting, pre-built agents, MCP support, agent-as-code configuration, serverless execution, credential isolation, and zero-trust networking (Benkovich et al., 26 May 2026).

The paper’s comparative discussion is specific. AgentCore is described as close in runtime and MCP support but AWS-locked and lacking declarative configuration and zero-trust. Claude Code cloud is vendor-specific and lacks the broader platform properties. Google AX is described as self-hostable and declarative but lacking credential isolation and zero-trust. kagent is described as Kubernetes-native and declarative but not serverless and lacking the security isolation features (Benkovich et al., 26 May 2026).

The principal strength claims are architectural rather than numeric. Agyn is presented as providing efficient on-demand execution without pre-provisioning, preserving state across cold starts, and offering a tighter combination of runtime, infrastructure-as-code, and security than the surveyed alternatives (Benkovich et al., 26 May 2026). This suggests that the contribution is a systems integration thesis rather than a performance-optimization result.

The paper also identifies several limitations as ongoing work. Per-exposure Dial policies are not yet scoped per user; spend-cap enforcement is metered but not hard-capped; ReBAC is not activated on all API paths; and the trust model for external runners is unspecified (Benkovich et al., 26 May 2026). These caveats are important because they qualify the maturity of the security and governance model. In particular, they indicate that the platform’s zero-trust posture is intended as a design direction and partially implemented system, not a fully closed operational story.

7. Terminological distinction and conceptual significance

Agyn should not be conflated with AGN, the “Attentional Gating Network” introduced for auditory source separation in “Auditory Separation of a Conversation from Background via Attentional Gating” (Mobin et al., 2019). AGN is a neural model that uses an embedding-based attentional context to separate one or more target speakers from a speech mixture, whereas Agyn is a Kubernetes-based platform for operating AI agents in production (Mobin et al., 2019). The similarity in orthography masks a complete difference in domain, objective, and technical substrate.

Within agent systems research, Agyn’s conceptual significance lies in its attempt to unify three concerns that are often handled separately: execution elasticity, declarative operational definition, and zero-trust security. The platform’s thread-centric runtime, harness-as-code model, and credential-isolating security structure are presented as a single operational design for bursty, stateful, privileged agent workloads (Benkovich et al., 26 May 2026). A plausible implication is that Agyn belongs less to the lineage of agent reasoning frameworks than to the lineage of cloud control planes and workload isolation systems adapted for non-deterministic, conversational software.

In that sense, Agyn marks a shift in emphasis from building agents to operating them: from prompt composition and tool use toward lifecycle control, policy enforcement, identity propagation, and organizational governance. That shift is the paper’s central systems claim (Benkovich et al., 26 May 2026).