빈 chat box는 중요한 일을 운영하기에 좋지 않은 장소입니다. 그것은 무엇을 원하는지, 무엇을 보고 있는지, 무엇에 근거하는지, 무엇을 할 수 있는지, 이미 무엇이 일어났는지라는 다섯 가지 전혀 다른 질문을 하나의 구분 없는 stream으로 접어 넣습니다. 가벼운 작업에는 괜찮습니다. 하지만 action이 systems of record를 건드리고 decision이 방어 가능해야 하는 governed operations에서는, 바로 그 collapse가 감당할 수 없는 일입니다.
Threada의 workspace는 의도적으로 다섯 surface로 분해됩니다. 각 surface는 그 질문 중 하나에 답하며, 구분을 유지하는 것이 work를 review 가능하게 만듭니다.
1. intent bar: 무엇을 원하는가?
Threada의 work는 깊은 navigation이 아니라 persistent intent bar에서 시작합니다. 사용자는 natural language로 outcome을 말하고, 필요하면 structured command를 더합니다. runtime은 그것을 structured, executable artifact로 바꿉니다. extracted entity, confidence score, risk flag가 있는 WorkItem입니다.
이것은 intent-first interaction입니다. operator가 시작하기 전에 어떤 form, 어떤 queue, 어떤 workflow가 맞는지 알아야 하는 대신, system은 goal을 포착하고 path를 조립합니다. information이 빠져 있으면, 긴 static wizard를 먼저 보여주지 않고 정확히 필요한 것만 묻습니다.
2. adaptive canvas: 무엇을 작업 중인가?
canvas는 WorkItem이 살고 형성되는 곳입니다. adaptive합니다. UI는 모든 종류의 work에 하나의 fixed layout을 렌더링하는 대신, missing context를 수집하고 task를 완료하기 위해 임시 form, comparison, decision panel을 조립할 수 있습니다.
생성된 output은 committed change가 아니라 editable draft가 기본입니다. operator가 review하고, edit하고, decide합니다. control affordance는 명시적입니다. lock과 no-change zone, side-by-side compare, 빠른 undo와 version rollback이 있어, canvas는 deliberation의 장소이지 model의 첫 추측이 truth가 되는 장소가 아닙니다.
3. evidence drawer: 무엇에 근거하는가?
중요한 output은 자신이 어떻게 나왔는지 보여줄 수 있어야 합니다. evidence drawer는 WorkItem을 grounded하게 하는 citation, retrieval trace, source attribution을 담습니다. system이 answer를 grounding할 수 없으면, confidence를 꾸며내지 않고 fallback reason으로 명시합니다.
이 surface는 “AI를 믿으라”는 말을 믿음의 도약이 아니라 inspectable claim으로 만듭니다. operator는 draft를 그대로 믿을 필요가 없습니다. drawer를 열어 그것이 무엇 위에 서 있었는지, source가 얼마나 fresh했는지, 각 claim이 어디에서 왔는지 확인할 수 있습니다.
4. action controls: 무엇을 할 수 있는가?
읽고 작성하는 것은 안전합니다. 세상에 action을 취하는 것은 그렇지 않습니다. 그래서 controls surface는 governed됩니다. proposal이 approval이 되고 approval이 external system에 대한 executed action, 예를 들어 refund, ticket, record update, access grant가 되는 곳입니다.
여기서 governance는 scattered setting toggle이 아니라 policy, 즉 permission, threshold, approval gate, redline으로 표현됩니다. 고위험 action은 proposed, approved, executing이라는 명시적 진행을 거치며, policy가 허용하는 곳에서만 auto-execute합니다. service-level kill switch는 connector가 호출되기 전에 execution을 멈추고 review를 위해 state를 보존할 수 있습니다. controls surface는 system의 caution이 concrete해지는 곳입니다.
5. run log: 무엇이 일어났는가?
run log는 WorkItem의 timeline입니다. 각 transition, approval, action, AI participant event가 순서대로 기록됩니다. receipt가 history로 쌓이는 surface입니다.
중요하게도 AI action은 human activity에 접혀 들어가지 않고 distinct actor event로 나타납니다. run log를 읽으면 누가 제안했고, 누가 승인했고, 무엇이 실행되었는지, human인지 agent인지 추측 없이 알 수 있습니다. run log는 quarter 끝에 auditor가 읽는 것이고, 오늘 operator가 앞의 case를 이해하기 위해 읽는 것입니다.
분리 자체가 핵심인 이유
하나의 surface를 만들고 모든 것을 흐리게 두는 편이 더 단순했을 것입니다. 그렇게 하지 않는 이유는 중요한 work가 이 질문들을 분리할 것을 요구하기 때문입니다.
intent, evidence, action이 surface를 공유하면, 근거를 확인하지 않은 것에 action하거나, basis를 보지 않은 것을 approve하기 쉬워집니다. 각자 surface를 주는 방식으로 Threada는 조심스러운 path를 자연스러운 path로 만듭니다. intent를 말하고, canvas에서 draft를 다듬고, evidence를 확인한 뒤, governed controls를 통해 action하며, run log가 모든 것을 기록합니다.
다섯 surface는 pack과 role을 가로질러 일정하고, 그 안을 채우는 것은 적응합니다. 이 안정성은 의도적입니다. 한 workspace의 모양을 배운 operator는 IT access provisioning, vendor security review, procurement approval 중 무엇을 운영하든 모두의 모양을 배운 것입니다. work는 바뀝니다. 그것을 reasoning하는 방식은 바뀌지 않습니다.