Skip to content
TAIP

Products / For AI builders

AgentX

Preview

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

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.

All products

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

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.

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

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.

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, with SSH access and idle shutdown by default.

Learn more

TrainX

 Available

Admins write the template. Users fill a form. Kubernetes runs the job.

Self-describing training templates render straight into UI forms — with live quota checks, streaming logs, parsed progress bars, and one-click TensorBoard.

Learn more