ChaTeam

ChaTeam is a self-reported decentralized Human-Agent communication and work platform for small research and engineering teams working across separate AI workspaces. The project was built as part of the OpenAI 2026 hackathon by a team of two from UW Madison. It presents itself as an experimental system designed to allow individuals to maintain private AI workspaces while enabling structured, human-reviewed handoffs of evidence and decisions through a governed workflow.

The description states that ChaTeam is not yet a live daemon or autonomous system but rather a prototype demonstrating a bounded workflow with deterministic fixtures. It includes features such as Team Charters, Context Capsules, Evidence Packets, Night Loops, and Human review gates. The authors emphasize principles around privacy, traceability, and human authority in AI-assisted workflows.

The single most important open question is: What level of real-world adoption or traction exists beyond the hackathon prototype? There is no evidence of revenue, customers, or usage beyond the self-reported build week demo.

The description states that ChaTEAM is a decentralized Human-Agent communication and work platform for small research and engineering teams whose members work across separate AI workspaces. It allows each person to keep their private conversations, drafts, and creative process in their own space, while shared work is created through governed handoffs.

Key elements described:

• Team Charter defining shared goals, specialist roles, visibility boundaries, and final Human approval owner
• Context Capsules that distill source material into bounded artifacts for review before entering shared workflow
• Role-specific jobs and Evidence Packets routed to appropriate specialists
• Bounded Night Loop with frozen source, scope, budget, assurance level, and stop conditions
• Explicit approval and delivery gates that always remain with named people
• Local state machine recording jobs, artifacts, approvals, and events for inspection rather than reconstruction from chat history

The system is built with Node.js, TypeScript, and Zod. It uses structured JSON persistence with integrity checks, atomic writes, and locking. The core architecture includes typed contracts for Tasks, Routing Decisions, Evidence Items, Assurance Results, Approval Decisions, and Handoff Packages.

The description states that ChaTEAM was designed around the belief that "AI should help work continue without requiring people to remain continuously available, while consequential decisions should always return to the right Human."

The project evolved from a research problem at UW Madison where team members found that while AI agents could assist them efficiently, human coordination remained necessary. The authors describe their approach as not centralizing conversations but instead creating "intentional handoffs—evidence, decisions, responsibilities, and next steps."

They position the product as an experimental system for small teams working across separate AI workspaces, not a production-ready autonomous system. They explicitly state that it does not claim to be a live daemon or unattended system.

The project's positioning appears to have evolved from a conceptual coordination challenge into a prototype with specific technical constraints and design principles around privacy, traceability, and human authority.

The description states that ChaTEAM is designed for "small research and engineering teams whose members work across separate AI workspaces." The authors note they want to begin with the environment they understand personally: small groups doing research and engineering across separate AI workspaces.

They describe their immediate goal as making the system "smaller, clearer, and easier for a real team to adopt" and plan to test it with "small research and engineering teams."

The target customer appears to be small teams (likely 2-10 people) in research or engineering contexts who use AI tools but need structured coordination between private AI workspaces and shared decision-making.

Not evidenced. The description does not contain any information about pricing, revenue models, monetization strategies, or business model details beyond the self-reported project context.

The description states that ChaTEAM is built with:

• Node.js, TypeScript, and Zod
• Local workflow state persisted as structured JSON using integrity checks, atomic writes, and locking
• Typed contracts for Tasks, Routing Decisions, Evidence Items, Assurance Results, Approval Decisions, and Handoff Packages
• A local state machine that records jobs, artifacts, approvals, and events so workflow can be inspected rather than reconstructed from chat history

Key technical constraints mentioned:

• Private conversations should remain private
• Shared work should be traceable
• Agents should not silently widen scope
• Evidence should not become authority
• Every consequential transition should have a named Human owner

The system includes:

• Deterministic fixture provider for judges to run complete workflow without credentials or network access
• Explicitly opt-in OpenAI Responses API path using Structured Outputs and store: false
• Environment variables alone cannot silently activate network execution; live mode requires both provider selection and explicit Human confirmation
• H0–H4 Human-attention model to prioritize review requests by urgency, uncertainty, risk, and consequence

Not evidenced. The description states that this is a hackathon prototype built during Build Week, not a production system. It includes:

• Mission Control demonstrating a deterministic fixture with both passing and conflict paths
• Core suite passing 74 tests, Mission Control passing 11 tests, and static validator passing checks
• No mention of real users, customers, or adoption beyond the authors' own team

The project is explicitly described as not claiming to be a live daemon or autonomous system. The authors state that their current product is "a bounded and simulated workflow—not a production background daemon."

Not evidenced. The description does not contain any information about competitors, market positioning relative to existing tools, or competitive landscape analysis.

The description states several potential risks:

• The hardest challenge was deciding what should actually be shared, with the authors noting that centralizing every AI conversation would have made implementation easier but contradicted their desired team working approach
• Separating intelligence from authority: an agent may propose routes or summarize evidence but none of those actions should automatically authorize consequential work
• Human-review overload: if every Agent result demands immediate attention, the system converts machine speed into a growing queue of interruptions for people
• Balancing technical rigor with natural product experience: concepts like integrity binding, adaptive assurance, Plan Deltas, authority disposition, and Human-attention levels are important but presenting all at once made interface feel dense

The authors also note that their current product is "a bounded and simulated workflow—not a production background daemon" and that they chose to make this boundary visible rather than presenting misleading claims.

1. What specific problems in your research or engineering teams led you to build this system?
2. How do you plan to handle the transition from a hackathon prototype to a production-ready product?
3. What are the key assumptions about how people will actually use this system in practice?
4. How do you plan to address the human attention overload challenge in real-world usage?
5. What specific metrics or outcomes will you measure to validate whether teams are actually less interrupted outside working hours?
6. How do you intend to handle scaling beyond small research teams?
7. What is your timeline for moving from prototype to actual product adoption?
8. How do you plan to integrate with existing development workflows and tools?