Trans4mers

Trans4mers lets a single user run an AI agent organization. Specialized agents collaborate in channels, exchange DMs, and execute complex workflows to accomplish real work like a true company.

Comment

Inspiration

As AI agents transition from research toys to enterprise tools, orchestrating them concurrently remains chaotic. Current multi-agent frameworks either rigidly hardcode the execution graph (inflexible) or let agents run completely wild with shared memory (unsafe). We realized that orchestrating AI is no longer a prompt engineering problem—it’s a distributed systems problem. Our inspiration was to build a deterministic control plane—a Swarm OS—where agents can dynamically scale and delegate tasks, but are strictly bound by enterprise constraints: isolated file sandboxes, granular mutex locks, and mandatory Human-In-The-Loop (HITL) yield points.

What it does

Trans4mers is a high-density, real-time agent orchestration workspace. When a user submits a complex goal, the system dynamically provisions a hierarchy of specialized sub-agents.

Instead of dumping every agent into a single, massive context window (which causes hallucination), Trans4mers forces agents to communicate via a Slack-style pub/sub model. Agents use a "Shared Blackboard" for global state consensus and private Direct Messages for peer-to-peer delegation. Crucially, agents execute real work—utilizing an isolated PTY terminal and file system to scaffold code and manipulate data, while the system enforces a strict HITL interrupt guardrail for any destructive actions.

How we built it

Frontend: Next.js (App Router), React Flow for real-time DAG topology visualization, and Zustand for state. Backend: Serverless, deployed on Google Cloud Run. AI Engine: GenKit 3 powering Gemini 3.5 Pro and Flash with a custom ReAct loop. Persistence: Neon Serverless PostgreSQL, utilizing pgvector for semantic memory. Concurrency Control: Distributed lease-based mutexes (SystemLock) and granular file locks to prevent agents from corrupting data during parallel operations.

Challenges we ran into

Race Conditions & Data Corruption: When multiple autonomous agents attempt to write to the file system simultaneously, they corrupt files. We had to implement granular FileLocks to serialize agent I/O operations. Serverless Real-Time State: Because Cloud Run scales containers horizontally, standard in-memory websockets drop state. We had to build a hybrid Server-Sent Events (SSE) implementation backed by a Postgres polling loop to synchronize agent actions across distributed instances. Context Bloat & 429 Quotas: Five agents running simultaneous ReAct loops instantly triggered Gemini 429 rate limits and flooded their context windows. We had to implement active queueing and LLM-driven context compaction (extractive summaries) to keep the agents focused. Runaway Zombies: Agents occasionally get stuck in infinite reasoning loops. We had to build a background cron job ("The Overseer") to monitor execution times and forcibly cull stuck swarms.

Accomplishments that we're proud of

The Sandboxed PTY Terminal: We successfully engineered a secure execution environment where agents can run CLI commands without risking root access, traversing directories, or leaking host environment variables. Autonomous Peer-to-Peer Delegation: We proved that a "Boss Agent" can autonomously recognize a gap in its capabilities, open a private DM channel with a specialized sub-agent, and delegate a sub-task entirely in the background without human intervention.

What we learned

Unpredictable LLMs act exactly like unreliable microservices. You cannot just give them tools and hope for the best; you must engineer around them using strict timeouts, retries, and distributed locks. We also learned that shared context is an anti-pattern for swarms. Forcing all agents to read a global chat log degrades performance. Agents need isolated state and a dedicated key-value store (our Shared Blackboard) to reach consensus.

What's next for Trans4mers We plan to expand the sandboxing capabilities to support fully ephemeral Docker-in-Docker workspaces per agent. We also want to deeply integrate the Model Context Protocol (MCP) so agents can securely ingest and mutate data in live enterprise databases (like Snowflake or Salesforce) under the same strict HITL governance model. Many more upgrades in memory, context, outputs, architectures etc. We are also planning to bring it for everyone as a open-source project so everyone can take advantage of it.

Built With

Share this project:

Updates

Submission history