One employee, one agent creates silos — the unit of AX is a governed workflow

The post diagnoses the right failure: giving every employee an isolated agent can raise local output while increasing organizational work-in-progress. The solution is not a larger swarm. Model one cross-team outcome as a durable workflow whose specialist agents share a case record, typed handoffs, policy gates, and an accountable human owner.

Choose one workflow that crosses at least three roles, such as lead → quote → contract → invoice. Give every run one case ID and append-only event log. Define each stage's input schema, output schema, owner, allowed tools, data scope, budget, completion test, timeout, and escalation. Agents may propose and execute inside those bounds; a durable orchestrator owns transitions and retries, while policy and high-risk approvals remain outside the agents. Compare end-to-end lead time, blocked time, rework, WIP, and exception rate—not documents per employee.

Why

The post's central distinction is local productivity versus system throughput. If a report agent produces ten drafts while legal, finance, or the next team can accept only two, eight drafts are inventory. Faster production before a bottleneck increases queue length, context decay, duplicate review, and reconciliation work. The organization did not become faster; it acquired a larger waiting room.

The architectural unit should therefore be the work item, not the employee or agent. One case record carries the goal, current state, evidence, decisions, approvals, and artifacts from beginning to end. Specialist agents are replaceable capabilities attached to workflow stages. They do not keep private memories of organizational truth or invent their own definition of done. A workflow transition occurs only when a machine-checkable completion contract passes.

Top-down does not mean one omniscient central agent. It means the organization defines shared semantics and control: identity, roles, permissions, data classification, budgets, state transitions, exception ownership, and audit. Teams can still build or personalize specialist agents bottom-up, but those agents plug into the same contracts. This preserves useful autonomy without creating thousands of incompatible products.

The autonomy target must also be bounded. 'Complete autonomy from start to finish' is unsafe as a universal objective because risk differs by step. Retrieval and drafting may be automatic; pricing exceptions, legal commitments, money movement, hiring decisions, and customer-visible publication may require deterministic checks or human approval. The correct goal is straight-through processing for ordinary cases plus an explicit exception queue—not pretending exceptions do not exist.

How it works

The minimum organizational control plane

Layer	Owns	Must not live only inside an agent prompt
Case record	goal, state, evidence, artifacts, decisions	organizational memory
Workflow contract	stages, schemas, completion tests, timeouts	definition of done
Policy engine	tool/data permissions, budgets, approval thresholds	authority
Durable orchestrator	transitions, retries, compensation, escalation	execution control
Agent registry	capability, version, owner, evaluation, retirement	lifecycle
Observability	trace, cost, queue time, exceptions, outcome	accountability

A state machine, not a group chat

INTAKE → QUALIFIED → QUOTED → LEGAL_REVIEW → APPROVED → EXECUTED → RECONCILED
              │             │                         │
              └─ reject     └─ exception queue        └─ compensate / escalate

Each transition requires typed evidence. Agents can perform stage work, but they cannot silently rewrite the state machine or grant themselves more authority.

One 30-day pilot

Pick one high-volume, bounded workflow with three or more handoffs.
Baseline lead time, wait time by stage, WIP, rework, and exception rate.
Create one case schema and event log before adding agents.
Add one specialist per bottleneck, beginning read-only and promoting only after replay evaluation.
Put money, legal commitments, external publication, and permission changes behind explicit gates.
Compare the whole workflow against baseline; stop if local output rises while end-to-end throughput does not.

The design rule

1 person ≠ 1 product
1 team = 1 governed workflow
many workflows = 1 shared organizational control plane

Source: the four supplied post screenshots. This report proposes an implementation pattern; the post's Cisco example and broad enterprise claims were not independently verified.

Where it lands in Jayverse

gitboard: model one real cross-repo workflow as a single case record. Pick a workflow that crosses rabbit, verex and wallet (say, PR → CI → deploy) and give every run one case ID with an append-only event log, instead of scattering per-repo agent output nobody aggregates.
CI: make each stage's completion test machine-checkable. Lint pass, tests pass, an invariant test pass — an agent's PR should only transition state when the contract is met, not when it merely claims done.
Auditor: keep policy and high-risk approvals outside any agent's autonomy. Mint changes, upgrade calls and permission changes belong behind an explicit gate the workflow enforces, exactly where the authority matrix already lives.

Key expressions

Words and phrases from this page worth keeping, with the Korean meaning and the sentence they come from.

Expression	뜻 · 쓰이는 자리
silo	사일로, 부서 간 단절된 구조 · 조직이 파편화되어 소통이 끊긴 상태. "creates silos"
work-in-progress (WIP)	진행 중인 미완료 업무(량) · 완료되지 못하고 쌓여 있는 작업을 가리키는 제조 관리 용어. "increasing organizational work-in-progress"
bottleneck	병목 지점 · 전체 흐름을 늦추는 한 단계. "before a bottleneck increases queue length"
straight-through processing	무중단(완전 자동) 처리 · 예외 없이 자동으로 끝까지 처리되는 흐름. "straight-through processing for ordinary cases"
exception queue	예외 처리 대기열 · 자동화에서 벗어난 사례들을 모아두는 큐. "plus an explicit exception queue"
completion contract	완료 조건(계약) · 한 단계가 끝났다고 판단하는 기계적 검증 기준. "a machine-checkable completion contract passes"
plug into	~에 연결되다, 통합되다 · 개별 에이전트가 공통 체계에 결합되는 것. "plug into the same contracts"
compensation	보상 처리, 원상복구 절차 · 실패 시 이전 상태로 되돌리는 처리. "transitions, retries, compensation, escalation"
grant oneself	스스로에게 (권한을) 부여하다 · 에이전트가 자기 권한을 임의로 늘리는 것을 경계할 때. "cannot silently... grant themselves more authority"
durable orchestrator	지속성 있는 오케스트레이터(실행 관리자) · 상태 전이와 재시도를 책임지는 중앙 실행 주체. "a durable orchestrator owns transitions and retries"
AX	에이전트 경험/도입 체계(Agent Experience) · 텍스트에 정의 없이 등장하는 약어, 이 카드에서 조직이 AI 에이전트를 도입하는 단위를 가리킴. "the unit of AX is a governed workflow"

← All Knowledge Notes · Workspace Index · Top ↑

직원 1명, 에이전트 1개는 사일로를 만든다 — AX의 단위는 통제되는 워크플로다

이 글은 정확한 실패를 짚습니다. 직원마다 고립된 에이전트를 주면 개인 산출량은 늘어도 조직의 Work-in-Progress가 커질 수 있습니다. 해법은 더 큰 agent swarm이 아닙니다. 하나의 팀 간 결과를 durable workflow로 모델링하고, 전문 에이전트들이 하나의 case record·typed handoff·policy gate·책임 있는 human owner를 공유하게 해야 합니다.

lead → quote → contract → invoice처럼 최소 세 역할을 지나는 workflow 하나를 고릅니다. 실행마다 하나의 case ID와 append-only event log를 줍니다. 각 단계의 input/output schema·owner·허용 tool·data scope·budget·완료 조건·timeout·escalation을 정의합니다. 에이전트는 그 경계 안에서 제안하고 실행하며, durable orchestrator가 transition과 retry를 소유하고 policy와 고위험 승인은 에이전트 밖에 둡니다. 직원당 문서 수가 아니라 end-to-end lead time·blocked time·rework·WIP·exception rate를 비교합니다.

왜

글의 중심 구분은 개인 생산성과 시스템 throughput입니다. 보고서 에이전트가 초안 10개를 만들어도 법무·재무·다음 팀이 2개만 받을 수 있다면 8개는 재고입니다. bottleneck 앞의 더 빠른 생산은 queue length·context decay·중복 review·reconciliation 작업을 늘립니다. 조직이 빨라진 것이 아니라 대기실이 커진 것입니다.

따라서 아키텍처의 단위는 직원이나 에이전트가 아니라 work item이어야 합니다. 하나의 case record가 목표·현재 상태·근거·결정·승인·artifact를 처음부터 끝까지 운반합니다. 전문 에이전트는 workflow stage에 붙는 교체 가능한 capability입니다. 조직의 진실을 private memory에 보관하거나 각자 완료 정의를 만들지 않습니다. machine-checkable completion contract가 통과할 때만 workflow가 다음 상태로 이동합니다.

Top-down은 모든 것을 아는 중앙 에이전트 하나를 뜻하지 않습니다. 조직이 identity·role·permission·data classification·budget·state transition·exception owner·audit라는 공통 의미와 통제를 정의한다는 뜻입니다. 팀은 specialist agent를 bottom-up으로 만들고 개인화할 수 있지만 같은 contract에 연결합니다. 그러면 유용한 자율성을 보존하면서 수천 개의 호환되지 않는 제품이 생기는 것을 막습니다.

자율성의 목표도 제한되어야 합니다. 단계마다 위험이 다르므로 '처음부터 끝까지 완전 자율'은 보편적 목표로 안전하지 않습니다. 검색·초안은 자동화할 수 있지만 가격 예외·법적 약속·자금 이동·채용 결정·고객 공개는 결정론적 검사나 human approval이 필요할 수 있습니다. 올바른 목표는 정상 case의 straight-through processing과 명시적인 exception queue이지, 예외가 없다고 가장하는 것이 아닙니다.

동작 방식

최소 조직 control plane

계층	소유하는 것	agent prompt 안에만 두면 안 되는 것
Case record	목표, 상태, 근거, artifact, 결정	조직 memory
Workflow contract	단계, schema, 완료 검사, timeout	완료 정의
Policy engine	tool/data 권한, budget, 승인 threshold	권한
Durable orchestrator	transition, retry, compensation, escalation	실행 통제
Agent registry	capability, version, owner, 평가, retirement	lifecycle
Observability	trace, cost, queue time, exception, outcome	책임성

Group chat이 아니라 state machine

INTAKE → QUALIFIED → QUOTED → LEGAL_REVIEW → APPROVED → EXECUTED → RECONCILED
              │             │                         │
              └─ reject     └─ exception queue        └─ compensate / escalate

각 transition에는 typed evidence가 필요합니다. 에이전트가 단계의 일을 수행할 수는 있지만 state machine을 조용히 다시 쓰거나 자기 권한을 늘릴 수는 없습니다.

30일 pilot 하나

handoff가 세 번 이상인 대량·제한된 workflow 하나를 고릅니다.
lead time·단계별 wait time·WIP·rework·exception rate baseline을 잡습니다.
에이전트를 붙이기 전에 case schema와 event log를 만듭니다.
bottleneck마다 specialist 하나를 read-only로 시작하고 replay 평가 뒤에만 승격합니다.
자금·법적 약속·외부 공개·권한 변경에는 명시적인 gate를 둡니다.
전체 workflow를 baseline과 비교하고, 개인 산출만 늘고 end-to-end throughput이 늘지 않으면 중단합니다.

설계 규칙

1 person ≠ 1 product
1 team = 1 governed workflow
many workflows = 1 shared organizational control plane

출처: 사용자가 제공한 게시물 스크린샷 4장. 이 보고서는 구현 패턴을 제안합니다. 게시물의 Cisco 사례와 광범위한 enterprise 주장은 별도로 검증하지 않았습니다.

Jayverse에서의 위치

gitboard: 실제 크로스 레포 워크플로우 하나를 단일 케이스 레코드로 모델링한다. rabbit, verex, wallet을 가로지르는 워크플로우(예: PR → CI → 배포)를 골라 매 실행마다 케이스 ID 하나와 추가전용 이벤트 로그를 부여한다. 아무도 취합하지 않는 레포별 에이전트 출력을 흩어놓는 대신이다.
CI: 각 단계의 완료 테스트를 기계로 확인 가능하게 만든다. 린트 통과, 테스트 통과, 불변식 테스트 통과 — 에이전트의 PR은 단순히 완료라고 주장할 때가 아니라 이 계약을 충족할 때만 상태가 전환되어야 한다.
Auditor: 정책과 고위험 승인은 어떤 에이전트의 자율성 밖에 둔다. 발행량 변경, 업그레이드 호출, 권한 변경은 워크플로우가 강제하는 명시적 게이트 뒤에 있어야 한다. 이는 이미 권한 매트릭스가 있는 바로 그 자리다.

핵심 표현

이 페이지의 영어 본문에서 배울 만한 단어와 표현, 뜻과 나온 자리.

Expression	뜻 · 쓰이는 자리
silo	사일로, 부서 간 단절된 구조 · 조직이 파편화되어 소통이 끊긴 상태. "creates silos"
work-in-progress (WIP)	진행 중인 미완료 업무(량) · 완료되지 못하고 쌓여 있는 작업을 가리키는 제조 관리 용어. "increasing organizational work-in-progress"
bottleneck	병목 지점 · 전체 흐름을 늦추는 한 단계. "before a bottleneck increases queue length"
straight-through processing	무중단(완전 자동) 처리 · 예외 없이 자동으로 끝까지 처리되는 흐름. "straight-through processing for ordinary cases"
exception queue	예외 처리 대기열 · 자동화에서 벗어난 사례들을 모아두는 큐. "plus an explicit exception queue"
completion contract	완료 조건(계약) · 한 단계가 끝났다고 판단하는 기계적 검증 기준. "a machine-checkable completion contract passes"
plug into	~에 연결되다, 통합되다 · 개별 에이전트가 공통 체계에 결합되는 것. "plug into the same contracts"
compensation	보상 처리, 원상복구 절차 · 실패 시 이전 상태로 되돌리는 처리. "transitions, retries, compensation, escalation"
grant oneself	스스로에게 (권한을) 부여하다 · 에이전트가 자기 권한을 임의로 늘리는 것을 경계할 때. "cannot silently... grant themselves more authority"
durable orchestrator	지속성 있는 오케스트레이터(실행 관리자) · 상태 전이와 재시도를 책임지는 중앙 실행 주체. "a durable orchestrator owns transitions and retries"
AX	에이전트 경험/도입 체계(Agent Experience) · 텍스트에 정의 없이 등장하는 약어, 이 카드에서 조직이 AI 에이전트를 도입하는 단위를 가리킴. "the unit of AX is a governed workflow"

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑