The Lab

Company brain on VKS

A company brain runs in git, separate from the lab infrastructure below. Specialists wake on a schedule as Kubernetes CronJobs, think on the DGX Spark, and write their homework back into the repo. They do not publish this site; I do.

How the company brain runs on VKSNumber One, reached by Cursor chat on the Tanzu worker, orchestrates four live specialists running as Kubernetes CronJobs in the insightout-brain namespace on VKS: marketing-research, niran-seo, dgx-optimizer and number-one-desk. They think on the DGX Spark and write their work into git, which feeds a read-only watch screen. Publishing this site stays a human decision.Number OneCursor chat · Tanzu workerSPECIALISTS · VKS CRONJOBS · NAMESPACE insightout-brainmarketing-researchdaily 06:00 UTC"write this next"LIVEniran-seoMondays 07:00 UTCmetadata patchesLIVEdgx-optimizerdaily 06:15 UTCmodel reportLIVEnumber-one-deskdaily 06:30 UTCimprovement questionsLIVE+ planned: IT ops · security gate · finance analyst · legal draftergit · insightout-brainmemory of the companynot committed = not knownDGX Sparkgpt-oss:120b · thinkingsame box as the lab aboveWatch screenHome · Results · Fleet · read onlyTAILSCALE ONLY, NOT PUBLICNiranreads the homework, decides, publishesNOT AUTOMATED
Four specialists are live, each on its own timer: research for what to write next, weekly SEO metadata, a daily DGX model report, and a daily set of company-improvement questions asked in chat. An IT ops agent, a security gate, a finance analyst and a legal drafter are planned, not built. None of them publish this site, switch the DGX model, or place a trade. Homework lands in git; I read it and decide.

DGX Spark

connecting

Orchestration

Cursor is the orchestrator. The primary worker runs on Tanzu; the agents box is the backup and the command centre. Nothing here is publicly reachable, and everything is reached over Tailscale.

How agentic work is orchestrated across the labCursor is the orchestrator. It drives two workers: a cursor-worker running as a Cloud Foundry app on Tanzu Platform, which is the primary, and the agents box, which is the backup and command centre. Both act on a nested estate containing Tanzu Platform and a VKS cluster, all running on VCF 9.1. Both Tanzu and VKS reach the DGX Spark for local inference on gpt-oss:120b.Cursororchestrator · auto model routingcursor-worker on TanzuCF app · python buildpackPRIMARYAgents boxClaude Code · Hermes · JarvisBACKUP + COMMAND CENTRENESTED ESTATE · ONE ROUTED DOORWAY INTanzu PlatformEAR · Postgres · GenAIagents · MCP servers · gatewayVKSprod-largeSupervisor · HarborVCF 9.1vCenter · NSX · vSAN ESA · Avi4 nested ESXi hosts on one ML350bothDGX Sparkgpt-oss:120blocal inferenceon the home LAN
Cursor drives the work. The primary worker runs as an ordinary Cloud Foundry app on Tanzu, scheduled and supervised by the platform; the agents box is the backup and the place I drive things from. Both Tanzu and VKS reach the DGX for local inference, through one scoped firewall exception rather than an open path to the house.

Agents on the platform

Both agents run as ordinary Cloud Foundry apps on the foundation they operate, and reach it through indexed API schemas rather than guesswork.

Agents and MCP servers running on Tanzu PlatformTwo agents run as Cloud Foundry apps: cursor-worker and tanzu-agent, which is bound to the DGX as an off-platform model. They reach the estate through an MCP gateway fronting two MCP servers, tanzu-mcp with 433 operations and vcf-mcp with 8,931, which in turn front Tanzu Platform and the VCF appliances.EVERYTHING BELOW RUNS AS AN APP ON THE FOUNDATION IT OPERATEScursor-workerCursor drives this remotelypython buildpacktanzu-agentbound to the DGX as a tile modelgpt-oss:120bMCP gatewaytoken decides capabilitytanzu-mcp433 operations5 tools, not one per endpointvcf-mcp8,931 operations7 targets, one interfaceTanzu PlatformCloud Foundry · Ops ManagerVCF appliancesvCenter · NSX · SDDC Mgr · Avi
Both agents run as ordinary apps on the platform they operate. Neither one guesses at an API: they search an index of nearly ten thousand operations and read the schema before calling anything. The gateway decides what each token is allowed to do, so capability is enforced server side rather than requested politely.

Infrastructure

Orchestration
Cursor · worker on Tanzu (primary), agents box (backup)
Private cloud
VCF 9.1 · 4 nested ESXi hosts · vSAN ESA · NSX · Avi
Platform
Tanzu Platform · Cloud Foundry, Postgres, GenAI tiles
Kubernetes
VKS · Supervisor · Harbor registry
Inference
DGX Spark · gpt-oss:120b · reached by Tanzu and VKS
Agent tooling
MCP servers · 9,364 operations behind twelve tools
Network
Tailscale mesh · VLAN isolation · no public ingress
Hardware
HP ML350 Gen10 · 512GB RAM · 350% memory tiering
Publishing
Agent → git → Vercel
Status API
/api/dgx-stats