AGenNext Platform

SDK-agnostic and model-agnostic configuration layer for AGenNext.

Looking for a quick start? See GET_STARTED.md for step-by-step instructions. For development workflow details, check DEVELOPMENT.md.

AGenNext is structured as:

AGenNext Platform
  └─ owns all user-facing configuration: SDKs, models, providers, framework selection, and integration choices
      ↓
AGenNext Runner
  └─ makes the system framework agnostic by loading the matching runtime bridge from Platform configuration
      ↓
AGenNext Kernel
  └─ makes the system infrastructure agnostic by executing on any deployment target

Note: Platform is the user-facing control plane. It supports all SDKs and exposes the model gateway experience so users can remain SDK agnostic and model agnostic. Platform owns the configuration experience; Runner consumes that configuration to load the correct bridge; Kernel executes on the selected infrastructure.

---

Role in AGenNext

AGenNext Platform is responsible for:

• SDK selection and SDK-specific configuration
• Model/provider selection through the model gateway
• Framework/runtime selection, such as LangGraph, CrewAI, AutoGen, LangChain, LlamaIndex, Mastra, Semantic Kernel, or custom runtimes
• Visual workflow and agent configuration
• User-facing configuration UX
• Persisting configuration that AGenNext Runner can consume
• Surfacing execution status, traces, usage, and billing data from runtime services

AGenNext Platform is not responsible for:

• Loading framework bridges directly; Runner does that
• Executing core kernel work; Kernel does that
• Owning deployment-target logic; Kernel is infrastructure agnostic
• Running local models directly; Runner provides runtime-side model gateway connectivity

---

Layer responsibilities

Layer	Agnostic boundary	Responsibility
AGenNext Platform	SDK agnostic and model agnostic	Supports all SDKs, exposes the model gateway, and owns all user-facing configuration
AGenNext Runner	Framework agnostic	Loads the selected runtime bridge and connects Platform configuration to Kernel/runtime services
AGenNext Kernel	Infrastructure agnostic	Executes on any deployment target selected by the operator/customer

---

Current implementation status

This repository contains a Next.js/React Flow visual orchestration UI starter.

Implemented today:

• Visual canvas using React Flow (@xyflow/react)
• Next.js 15 + React 19 + TypeScript application structure
• Zustand state stores for flow, UI, and platform configuration
• shadcn/Radix-style UI component setup
• Tailwind CSS styling
• Starter node/canvas/sidebar/topbar structure
• Typed PlatformConfig model (src/types/platformConfig.ts)
• Catalog files (SDK, model provider, framework, bridge, kernel deployment)
• PlatformConfigStore with getRunnerPayload and validateConfig
• Platform configuration UI panels
• API client layer (runnerClient, kernelClient)
• Platform REST APIs (/api/flows, /api/sdks, /api/models, /api/providers, /api/frameworks, /api/bridges, /api/execute, /api/status, /api/usage)
• Redoc API documentation at /api-docs

Still to wire

• Full Runner API integration
• Real persistence backend
• Kernel endpoint health checks
• Trace, billing, usage, and policy views

---

Configuration ownership

All user-facing configuration belongs in Platform.

Examples:

SDK choice              → Platform
Model/provider choice   → Platform model gateway UX
Framework choice        → Platform
Runtime bridge mapping  → Platform config consumed by Runner
Kernel deployment view  → Platform displays/configures endpoint metadata
Execution engine        → Kernel
Bridge loading          → Runner

Runner should receive a normalized configuration payload from Platform, such as:

{
  "sdk": "typescript",
  "modelGateway": {
    "provider": "ollama",
    "model": "qwen3:30b-a3b"
  },
  "framework": "langgraph",
  "runtimeBridge": "bridges/langgraph",
  "kernelEndpoint": "https://kernel.<your-domain>",
  "observability": {
    "tracing": true,
    "billing": true
  }
}

---

Technology stack

Layer	Library	Version
Framework	Next.js 15 + React 19 + TypeScript	^15.0.0 / ^19.0.0
Canvas	@xyflow/react / React Flow	^12.x
UI Components	shadcn/Radix-style components	latest
Styling	Tailwind CSS	^3.4.1
Icons	Lucide React	^0.468.0
State	Zustand	^4.x / ^5.x pattern
Server State	TanStack Query	^5.x

---

Project structure

platform/
├── src/
│   ├── app/
│   ├── components/
│   ├── nodes/
│   ├── stores/
│   ├── types/
│   ├── lib/
│   └── styles/
├── package.json
├── tsconfig.json
├── tailwind.config.ts
├── postcss.config.js
├── next.config.js
└── README.md

---

Getting started

Prerequisites:

• Node.js >= 18.17.0
• npm >= 9.0.0

npm install
npm run dev

Type check and lint:

npm run type-check
npm run lint

Build:

npm run build
npm start

---

Environment variables

NEXT_PUBLIC_PLATFORM_API_URL=http://localhost:3000/api
RUNNER_ENDPOINT=http://localhost:4000
NEXT_PUBLIC_RUNNER_API_URL=http://localhost:4000
NEXT_PUBLIC_MODEL_GATEWAY_URL=http://localhost:4000/v1
NEXT_PUBLIC_KERNEL_ENDPOINT=http://localhost:8080

Use deployment-specific values in production.

---

Planned Platform APIs

Platform should expose or call APIs for:

Area	Example
Flow persistence	GET /api/flows/:id, POST /api/flows, PUT /api/flows/:id
SDK catalog	GET /api/sdks
Model gateway catalog	GET /api/models, GET /api/providers
Framework/runtime catalog	GET /api/frameworks, GET /api/bridges
Runner execution	POST /api/runs or proxy to Runner
Kernel status	GET /api/kernel/status
Traces and usage	GET /api/traces, GET /api/usage

---

Relationship to Runner and Kernel

Platform owns configuration.

Runner consumes Platform configuration and loads the matching runtime bridge.

Kernel executes the workload on any supported infrastructure target.

User configuration → Platform
Runtime bridge loading → Runner
Infrastructure-agnostic execution → Kernel

---

Security

• Do not hardcode secrets.
• Store local development values in .env.local.
• Keep provider secrets server-side.
• Only expose safe public URLs through NEXT_PUBLIC_* variables.
• Use backend routes or Runner APIs for sensitive operations.

Need more details? Check the full security guidance in QUICK_REFERENCE.md.

---

Deployment

Vercel

npm install -g vercel
vercel

Docker

FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install && npm run build
CMD ["npm", "start"]

---

Production-oriented status

Platform includes production-oriented building blocks, but requires environment-specific hardening before production deployment:

Core

• Prisma - PostgreSQL persistence with multi-tenant schema
• NextAuth - Multi-tenant authentication with SSO support
• Secrets - AES-256-GCM encryption, API key rotation
• Redis - Session cache, execution state caching

Billing

• Stripe - Customer management, subscription billing
• Usage metering - Execution tracking for billing

Observability

• Langfuse - LLM tracing and metrics
• OpenTelemetry - Auto-instrumentation for HTTP/Express
• Audit logs - SOC 2 compliant event logging

Infrastructure

• K8s manifests - Production deployment configs
• Docker Compose - Local development stack
• CI/CD - GitHub Actions workflow

APIs Implemented

Endpoint	Description
POST /api/execute	Execute flow via Runner
GET/POST /api/flows	CRUD flows
GET /api/execute?id=	Execution status
GET /api/auth/[...nextauth]	NextAuth handlers

Environment Variables

DATABASE_URL=postgresql://...
NEXTAUTH_SECRET=...
STRIPE_SECRET_KEY=...
ENCRYPTION_KEY=...
REDIS_URL=redis://...
RUNNER_ENDPOINT=http://localhost:8081
LANGFUSE_PUBLIC_KEY=...
LANGFUSE_SECRET_KEY=...

---

License

MIT. Feel free to update as needed for your deployment.

Authorization, identity, and interoperability configuration

Platform defines and versions tenant-scoped authorization and identity configuration for Runner consumption:

• OPA policy management with tenant_id, policy_id, policy_version, bundle_version, created_at, updated_at.
• AuthZEN mapping configuration (subject, resource, action, context) for translating Platform concepts into authorization tuples.
• OpenFGA configuration metadata (tenant-scoped store/model metadata and relation model scaffolding for tenant, user, agent, tool, workflow, memory, repo).
• Agent identity registry (agent_id, tenant ownership, lifecycle status, credential/workload identity binding metadata).
• Agent protocol publishing config (A2A/ACP/Agent Client/Agent Network protocol enablement, trust domains, visibility, capability publication).
• Runner handoff output at GET /api/config/runner-handoff?tenant_id=<id> with policy/model versions, enabled engines, trust policy, and allowed scopes.

Responsibility split:

• Platform defines/stores/versions/publishes configuration.
• Runner enforces OPA/AuthZEN/OpenFGA and runtime guardrails.
• Kernel executes only prevalidated work and persists audit/trace metadata.

Production readiness status

AGenNext Platform is a production-oriented starter and control-plane scaffold.

It should not be considered production-ready until security, secrets, CI/CD, observability, and operational hardening controls are completed and verified.