Skip to content
TAIP

Products / For AI builders

AgentX

Preview

Agents as a first-class Kubernetes primitive — versioned, sandboxed, fully traced.

Author a versioned Agent, then run it as Sessions — autonomous tasks or interactive chat — on Kubernetes. Per-session sandbox isolation with deny-by-default egress, built-in / MCP / custom tools, cross-session memory, cron schedules, always-on services, and a live event trace with token accounting — behind an OIDC SSO front door with per-user sessions. All reconciled from CRDs on agent.tensorstack.dev.

Proof, not promises All products
Release
v0.1.0-rc1 preview
CRDs
5 on agent.tensorstack.dev
Tracing
Step · tool · token

Overview

AgentX

AgentX makes LLM agents a platform primitive on TAIP. You author a reusable, versioned Agent definition — model, system prompt, tools, memory, sandbox — and run it as AgentSessions; the agentx-controller provisions a hardened sandbox Pod that runs an in-house, provider-agnostic agent loop and streams every step to a durable event store. Models come from InferX (OpenAI-compatible, gemma-4) over a pluggable adapter; tools are built-in (bash / file / code / web), MCP servers, or custom host-side tools that keep secrets out of the sandbox. Layer on cron AgentSchedules, always-on AgentServices, and persistent MemoryStores — all referencing the same Agent. A React trace viewer and chat UI, plus a taip-agent CLI, read the live SSE stream with just a kubeconfig. An OIDC SSO front door (agentx-bff) adds browser login, group-to-role RBAC, and per-user session ownership, and each sandbox runs under a deny-by-default CiliumNetworkPolicy that fails closed.

Proof, not promises

See it in one block.

No proprietary SDKs, no rewrites — AgentX meets your tools where they already are.

an agent is just a CRD 
$ kubectl apply -f agent.yaml         # a versioned Agent definition
agent.agent.tensorstack.dev/demo  created
$ kubectl apply -f session.yaml       # one run of it
agentsession/demo-run-1  created
$ kubectl get agentsession demo-run-1 -w
demo-run-1   Pending → Running → Succeeded   # hardened sandbox Pod
$ taip-agent trace demo-run-1          # live SSE: every step, tool call, token
# usage: 1,284 in · 412 out tokens · attributed to this run▌

Agent, AgentSession, AgentService, AgentSchedule, MemoryStore — five CRDs on agent.tensorstack.dev. Declarative, GitOps-friendly, observable with the Kubernetes tools you already run.

Capabilities

What AgentX gives you

01

Versioned Agent definitions

Author an Agent once — model, system prompt, tools, memory, sandbox — then run it many times. The resolved spec is snapshotted into a per-session ConfigMap at create time, so runs stay reproducible across later edits.

02

Sessions: autonomous or interactive

An AgentSession is one run — a fire-and-forget task or a multi-turn conversation. The loop parks at Idle between turns and resumes on follow-ups; the controller enforces timeouts, TTL, and token budgets.

03

Built-in, MCP, and custom tools

bash, file, code, and web run inside the sandbox. MCP servers wire in over a Streamable-HTTP client. Custom host-side tools pause the loop and resume on an external result — so tool secrets never enter the sandbox.

04

Hardened, isolated, and signed-in

Every run gets its own Pod: runAsNonRoot, dropped capabilities, no service-account token, read-only config mount, and a deny-by-default CiliumNetworkPolicy that fails closed on egress. An OIDC SSO front door signs people in and scopes each user to their own sessions. Ask-gated tools pause for an approve / deny decision before they run.

05

Trace every step

A durable, PVC-backed event store records every tool call, assistant message, status change, and token count — streamed live over SSE and replayable after a restart. Usage is attributed per run.

06

Cross-session memory

A MemoryStore is a persistent (optionally RWX) PVC mounted into an Agent's sessions, so an agent remembers across runs — with optional retain to outlive the store.

07

Schedules and always-on services

An AgentSchedule fires Sessions on a timezone-aware cron with concurrency policy and history limits. An AgentService turns each HTTP request into a fresh Session behind a scoped gateway — async or sync.

08

UI and CLI on one stream

A React trace viewer and chat UI proxy to an AgentService gateway; the taip-agent CLI runs, lists, gets, and tails the live trace from Pod logs with just a kubeconfig.

How it works

From definition to traced run, on Kubernetes.

  1. Step 01

    Author an Agent

    Declare the model (InferX), system prompt, tools, memory, and sandbox in a versioned Agent CRD. YAML-first and GitOps-friendly — kubectl apply or taip-agent.

  2. Step 02

    Run a Session

    Start an AgentSession — a task or a chat. The controller snapshots the spec and provisions a hardened sandbox Pod running the agent loop against your model and tools.

  3. Step 03

    Watch the trace

    Every step, tool call, and token streams live over SSE to the trace viewer, chat UI, or taip-agent CLI — durable and replayable, with usage attributed to the run.

  4. Step 04

    Schedule or serve it

    Promote the same Agent to a cron AgentSchedule or an always-on AgentService — and give it a MemoryStore to persist context across runs.

Specification

Status
v0.1.0-rc1 — preview, validated end-to-end
CRDs
Agent · AgentSession · AgentService · AgentSchedule · MemoryStore
Models
InferX adapter (OpenAI-compatible, gemma-4) · provider-agnostic loop
Tools
Built-in bash/file/code/web · MCP (Streamable-HTTP) · custom host-side
Tracing
Durable PVC-backed event store · live SSE · token usage per run
Isolation
Per-session sandbox Pod (non-root, dropped caps) · deny-by-default Cilium egress · opt-in HMAC
Identity
OIDC SSO front door (agentx-bff) · group→role RBAC · per-user sessions
Surfaces
React trace viewer + chat UI · taip-agent CLI · Helm + kustomize

Who it's for

Built for these teams

  • Teams building production agent products on their own infrastructure
  • Platform teams offering agents as a governed, multi-tenant service
  • SRE and ops teams automating runbooks with scheduled, gated agents
  • Researchers exploring agentic systems with full traces and replay

Where it fits

AgentX in the TAIP stack

Every product shares one identity, one quota model, and one audit trail with the rest of the platform. Here is where AgentX sits.

L5

AI applications

Knowledge and agents your teams build on

GrokX AgentX

L4

AI lifecycle

Develop → train → register → serve

DevSpace TrainX Slurm on TAIP ModelSphere ImageSphere InferX

L3

Control plane

Tenancy, operations, and accounting

ConsoleX TAIP Admin TAIP Billing

L2

Foundation

Kubernetes, identity, storage, networking

TAIP Base

L1

Your hardware

On-prem · VPC · air-gapped

NVIDIA AMD Intel Ascend Cambricon Ceph · Longhorn

Pairs well with

Other builder products

ConsoleX

 Available

Log in, get a governed Kubernetes workspace. No kubectl, no tickets.

On first SSO login every user gets an isolated namespace with quotas, default-deny networking, storage, and a web terminal — provisioned automatically, reconciled continuously. It is also the platform's front door: the token authority every TAIP app trusts, the SSH gateway into every workspace, and the taip CLI the cluster serves itself.

Learn more

DevSpace

 Available

Jupyter or VS Code on a GPU in seconds. Idle environments shut themselves down.

Single-click Jupyter, Marimo, Streamlit, Gradio, and VS Code environments — GPU-ready, isolated per user behind a per-pod auth proxy, shareable with a colleague, and idle-shutdown by default.

Learn more

TrainX

 Available

A template is a shape. Your project fills it. Kubernetes runs the job.

Self-describing templates render straight into UI forms — or your project declares itself in a trainx.yaml and runs on a platform shape. Live quota checks, streaming logs, parsed progress, MLflow-tracked parameters and metrics, resumable runs, and declared outputs you can hand to the next step.

Learn more