TeamDynamics

multi-agent-system ai-agents team-simulation crisis-simulation decision-making organizational-behavior llm generative-ai fastapi nextjs websocket python typescript postgresql

Comment

TeamDynamics — Project Story

Inspiration

TeamDynamics was inspired by Manusia Stoik and the Stoic practice of Premeditatio Malorum: deliberately imagining possible misfortunes before they happen so that we can prepare for them more rationally.

I realized that this principle could also be applied to how organizations prepare for crises. Teams often make critical decisions only after a problem has already escalated: a sudden resignation, mass layoffs, a production database failure, an approaching deadline, or the loss of an important client. At that point, the consequences are already real, and experimenting with different responses can be costly.

This led me to one central question:

What if a team could rehearse a crisis before facing it in the real world?

I translated Premeditatio Malorum into the architecture of TeamDynamics. Instead of merely asking an AI chatbot what might happen, users can construct a virtual organization, introduce a crisis, observe how different AI agents respond under pressure, and test possible interventions in a controlled environment.

TeamDynamics is not intended to predict human behavior with certainty. It is a decision-rehearsal environment: a safe place to explore possible reactions, trade-offs, and failure patterns before making decisions that affect a real team.

What it does

TeamDynamics is a multi-agent AI crisis simulation platform for founders, engineering managers, HR leaders, and team leads who need to reason about difficult organizational decisions before the stakes become real.

Users begin by describing a company and assembling a virtual team. Each AI agent has a role, expertise, motivation, memory, and five personality traits: empathy, ambition, stress tolerance, agreeableness, and assertiveness. These traits do more than change the wording of a response. They influence how an agent communicates, reacts to conflict, supports proposals, and experiences changes in morale, stress, loyalty, and productivity.

A crisis can come from a predefined scenario, a custom situation, or an uploaded organizational document. TeamDynamics can analyze PDF, DOCX, CSV, and XLSX files to extract relevant context, identify risks, recommend a crisis, and suggest suitable roles for the simulation.

Once the simulation starts, the organization becomes a living system. Through a real-time, Slack-inspired interface, users can observe:

  • Public statements and private internal thoughts from each agent
  • Personality-weighted changes in morale, stress, loyalty, and productivity
  • Proposals, negotiations, and hierarchy-weighted voting
  • Burnout, resignation, and other critical events
  • Changes in budget, reputation, customer satisfaction, technical debt, team capacity, and deadline pressure
  • Unexpected events that force the team to adapt

The simulation progresses through five phases: crisis shock, debate and proposals, escalation, resolution attempt, and aftermath. Dialogue changes agent state; agent decisions change the organization; and the evolving organization changes what the agents do next.

The user is not limited to watching. God Mode interventions make it possible to pause the simulation, preview a targeted action, apply it to an agent, team, project, or decision process, inspect its impact, and safely undo eligible changes. This turns TeamDynamics from a passive AI conversation into an interactive decision laboratory.

At the end, TeamDynamics produces an executive report that connects the final outcome to the agents, decisions, interventions, critical events, and metric changes that produced it. The goal is not just to say what happened, but to make the path to that outcome understandable.

How I built it

I built TeamDynamics as a full-stack system with clear frontend, backend, persistence, simulation, real-time communication, and AI-provider layers.

The frontend uses Next.js 16, React 19, TypeScript, Tailwind CSS, shadcn/ui, Framer Motion, and Recharts. It contains the guided setup experience, document-assisted autofill, agent configuration, live simulation workspace, intervention controls, metric visualizations, dashboard, replay, comparison, and executive reports.

The backend uses Python, FastAPI, and Uvicorn, with PostgreSQL and asyncpg for persistent users, teams, simulations, agent states, messages, decisions, interventions, and results. Native FastAPI WebSockets stream agent messages, typing states, metric updates, critical events, votes, and simulation progress while the backend remains the authoritative source of truth.

The core is a stateful simulation engine rather than a collection of isolated chatbot calls. It combines personality-weighted state transitions, agent memory, hidden motivations, individual objectives, a five-phase crisis model, hierarchy-weighted decisions, random events, and a persistent organizational world state. This is what allows a conversation, a vote, or an intervention to create consequences that remain relevant in later rounds.

TeamDynamics supports a Bring Your Own AI architecture with OpenAI, Google Gemini, and OpenRouter provider paths and per-agent model configuration. The application's default OpenAI runtime model is currently gpt-4o-mini. The public no-login Quick Demo intentionally uses deterministic agent responses so judges can reliably experience the product without an API key or external model cost, while still exercising the real simulation engine, state mutations, persistence, WebSocket stream, decision tracking, interventions, and outcome generation.

OpenAI's role in building TeamDynamics goes beyond the runtime API. I used OpenAI Codex throughout the development journey, first with GPT-5.4, then GPT-5.5, and now GPT-5.6. These models were used through Codex as an engineering collaborator—not as TeamDynamics' deployed inference model. Codex helped me explore the repository, implement features, trace frontend and backend behavior, debug failures, review architecture, strengthen reliability and security, improve documentation, and verify changes. I remained responsible for the concept, product direction, architectural decisions, trade-offs, and final validation.

From the early stages of the project, I also paired Codex with TestSprite. TestSprite exercised real product flows and exposed behavioral failures; Codex helped me inspect the evidence, trace each failure to its root cause, implement a focused fix, and verify the flow again. That repeated build–test–learn loop shaped TeamDynamics long before this submission and continued as I refined the judge experience.

The frontend is deployed on Vercel, while the backend and PostgreSQL infrastructure run through Railway.

Challenges I ran into

The first major challenge was keeping agents meaningfully different across an entire simulation. A personality paragraph inside a prompt was not enough: agents could drift between rounds or gradually sound identical. I addressed this by connecting personality to both communication and numerical state transitions. Stress tolerance affects how quickly stress rises, ambition influences productivity resilience, empathy shapes reactions to negative team conditions, and previous events remain part of the agent's context.

The second challenge was real-time consistency. Messages, internal thoughts, decisions, votes, interventions, metrics, critical events, and final reports all describe the same evolving organization. If the frontend and backend disagreed, even briefly, the simulation became difficult to trust. I kept state transitions authoritative on the backend and used WebSockets to deliver a consistent stream of events to the interface.

Another challenge was information overload. A multi-agent simulation can generate more activity than a user can reasonably follow. I had to repeatedly refine the information architecture so that the conversation remains readable while the larger organizational condition, causal changes, and intervention opportunities stay visible.

The hardest challenge, however, was finishing the product as a solo developer. Building an ambitious prototype was only the beginning. Turning it into a coherent end-to-end experience required me to connect simulation logic, document processing, authentication, persistence, real-time events, frontend clarity, reports, testing, deployment, and submission evidence. Every improvement could reveal another edge case in a different layer.

Working alone forced me to prioritize ruthlessly. I could not polish every possible feature, so I focused on the complete decision journey: set up a team, introduce a crisis, observe consequences, intervene, and understand the result. Codex helped me move across the stack, while TestSprite gave me repeatable evidence about where the real user journey still broke. The difficult finishing work taught me that a compelling AI product is not defined by its first impressive response; it is defined by whether the whole experience holds together.

Accomplishments that I'm proud of

I am proud that TeamDynamics turns an abstract philosophical practice into a functioning software architecture. Premeditatio Malorum is not simply part of the project's branding. It is expressed through the complete workflow: imagine a crisis, construct a team, observe consequences, test an intervention, and study the outcome before real people and resources are at risk.

I am also proud that the agents are more than separate chatbot windows. Their personalities influence communication, internal state, memory, decisions, and reactions to organizational pressure, while their combined actions change a persistent company-level world state.

TeamDynamics earned third place in the international TestSprite Hackathon Season 2, competing among 45 projects from participants around the world. The result was announced by TestSprite and later recognized by my university, Telkom University:

That recognition matters to me because it validated not only the idea, but also the engineering loop behind it: building with AI, testing real behavior, learning from failures, and continuing until the product became stronger.

Other accomplishments I am proud of include:

  • Building a persistent multi-agent simulation rather than a scripted chat interface
  • Connecting individual psychology to organization-level consequences
  • Creating auditable interventions with preview, receipts, and safe undo behavior
  • Turning uploaded company documents into grounded setup recommendations
  • Streaming the simulation in real time through WebSockets
  • Producing executive reports that explain outcomes instead of presenting only a score
  • Delivering an accessible public demo and a deployed end-to-end application
  • Using successive generations of Codex models and TestSprite as a continuous engineering and verification workflow

What I learned

I learned that Stoic philosophy can have a practical place in software engineering. Premeditatio Malorum can become a structured process for examining risks and rehearsing decisions before a real incident forces an organization to react.

I learned that multi-agent systems need more than different prompts. Distinguishable behavior requires memory, state, constraints, incentives, and consequences. Without those elements, multiple agents are often just multiple versions of the same chatbot.

I also learned to be careful about what a simulation claims. Human teams are far more complex than AI agents. TeamDynamics is most useful when its output is treated as a set of hypotheses for discussion, not as a guaranteed forecast of what real employees will do.

Another lesson was that generating more information does not automatically produce more insight. Interface design and information architecture are part of the reasoning system. Users need to see not only events and metrics, but also the causal thread connecting decisions to outcomes.

Using Codex taught me how much AI can accelerate exploration, implementation, debugging, and review across a full-stack codebase. Using TestSprite taught me the complementary lesson that speed needs verification. An agent can generate a plausible change quickly, but a real product flow provides the evidence that tells me whether the change actually works.

Most importantly, I learned that finishing is its own engineering discipline. Integration, failure handling, edge cases, deployment, documentation, and a clear demonstration can demand more effort than the initial feature. AI accelerated my work, but it did not replace my responsibility to choose the direction, evaluate trade-offs, and decide when the product was honest and coherent enough to present.

What's next for TeamDynamics

My next objective is to make TeamDynamics more powerful for comparing decisions rather than observing only one possible future.

I plan to build parallel simulation comparison and counterfactual analysis, allowing a user to run the same crisis with different teams, policies, or interventions and inspect where the outcomes diverge. Instead of asking only “What happened?”, TeamDynamics should help answer “What changed the trajectory?” and “Which intervention produced the most resilient outcome?”

Other directions include:

  • Agent-to-agent private communication for hidden alliances and negotiations
  • Historical replay with complete playback controls
  • Reusable team, organization, crisis, and intervention templates
  • Custom personality dimensions beyond the five default traits
  • Stronger comparison of intervention timing and downstream consequences
  • Collaboration features for multiple observers and decision-makers
  • Integrations with Slack and Microsoft Teams
  • Organizational analytics across multiple simulations

In the long term, I want TeamDynamics to become a flight simulator for organizational decisions: a place where leaders can safely explore difficult scenarios, challenge their assumptions, compare possible responses, and make better-informed decisions before real people and resources are at risk.

Built With

Share this project:

Updates