디자인 시스템을 다시 보니, 나는 이미 의미 계층을 만들고 있었다

이 글은 예전 디자인 시스템을 현재의 용어로 과장해 재명명하려는 글이 아니다. 당시에는 왜 그렇게까지 속성과 관계를 나눴는지 설명하기 어려웠던 작업을 다시 보며, 그 습관이 금융 UX, 문서의 문맥 모델링, NLU와 온톨로지, 그리고 Agent UX로 어떻게 이어졌는지 추적하려는 기록이다.

먼저 디자인 시스템의 semantic token과 component property에서 출발한다. 다음으로 ETF 화면과 Context Engine 사례를 통해, 그 구조가 사용자의 판단 순서와 문서의 의미 관계를 다루는 방식으로 넓어졌음을 본다. 그 뒤 Agent UX에서 이 문제가 왜 Task Visibility가 아니라 Shared Situation Awareness의 문제가 되는지, 리서치가 제시하는 상태·근거·불확실성·개입·기억의 설계 조건을 붙인다. 마지막에는 이 흐름을 하나의 직무 전환 서사가 아니라, 사람이 이해하는 관계를 시스템 구조와 다시 연결해 온 작업 방식으로 되돌아본다.

오래된 포트폴리오를 다시 열었다. Foundation, Core Components, Components Labs, Page Pattern, Product Pages. 예전에는 이 다섯 칸을 잘 정리된 디자인 시스템의 목차라고 생각했다.

그런데 지금 보니 질문이 바뀐다.

“이거 온톨로지 아니냐?”

물론 아니다. RDF나 OWL로 적은 엄밀한 온톨로지는 아니었다. 당시 내가 만든 것은 색, 타이포그래피, 레이아웃, 버튼, 메뉴, 화면을 재사용하기 위한 디자인 시스템이었다. 과거 작업에 현재의 용어를 덮어씌워 특별한 무엇이었다고 말하고 싶지는 않다.

다만 그 안에는 지금의 내가 알아보는 습관이 있었다. 화면을 먼저 그리지 않고, 무엇이 존재하는지와 무엇이 무엇을 가리키는지를 먼저 정리하는 습관이다.

Raw Color
→ Token
→ Semantic Color
→ Component
→ Pattern
→ Product UI

파란색 #4285F4가 화면에 바로 놓이지 않았다. 먼저 토큰이 되고, 그 다음 primary, information, selected 같은 역할을 받고, 버튼이나 배지, 내비게이션에 쓰였다. 값과 역할을 갈라야 다크 모드나 화이트 라벨, 화면별 변형이 와도 같은 말을 할 수 있었기 때문이다.

버튼도 마찬가지였다. 버튼 하나를 만들고 끝내는 대신, Content, Action, State, Behavior 같은 속성으로 나눴다. 무엇을 보여주는가, 무엇을 실행하는가, 눌릴 수 있는가, 지금 어떤 상태인가. 나중에 화면이 달라져도 이 질문들은 남는다.

Component
├─ hasContent
├─ hasAction
├─ hasState
├─ hasVisualRole
└─ hasInteractionBehavior

지금의 온톨로지 언어로 쓰면 class, property, relation에 가까워 보인다. 당시에는 그런 말을 쓰지 않았다. 그러나 컴포넌트를 모은 것이 아니라, 서로 다른 사람이 같은 컴포넌트를 같은 것으로 인식할 수 있는 조건을 만들려 했다는 점은 분명하다.

“그게 왜 필요하죠?”

당시 조직에는 시니어 프론트엔드 개발자가 없었다. 디자이너에게는 자연스러운 affordance, property, state, semantic token이라는 말이 개발자에게는 낯선 말이었다. 설명을 시작하면 자주 이런 질문이 돌아왔다.

“그게 왜 필요하죠?”

처음에는 답답했다. 그런데 지금은 그 질문이 맞는 질문이었다고 생각한다. 공통 언어가 없는 상태에서 컴포넌트부터 던져주면, 사람마다 다른 버튼을 떠올린다. 한 사람은 시각 모양을, 다른 사람은 클릭 가능한 영역을, 또 다른 사람은 비활성 상태의 정책을 떠올린다. 이름은 같지만 대상은 다르다.

그 상태에서 라이브러리를 늘리는 일은 시스템을 만드는 일이 아니다. 같은 단어 아래에 다른 가정을 더 많이 쌓는 일이다.

그래서 그때 더 오래 걸린 것은 화면을 만드는 일이 아니라, 화면을 설명할 수 있게 만드는 일이었다. 무엇을 같은 것으로 볼지. 무엇을 상태로 분리할지. 어떤 예외가 규칙을 깨는지. 무엇을 재사용 가능하다고 부를지. 디자이너와 개발자가 같은 대상을 보게 만드는 중간 계층이 먼저 필요했다.

색과 아이콘은 판단을 위한 언어였다

금융 서비스의 ETF 상세 화면을 설계할 때도 관심은 컴포넌트 일관성에서 끝나지 않았다. 국내 ETF와 미국 ETF를 보는 사람의 목적이 다르고, 가격 판단에 필요한 정보의 변화 주기도 다르다. 어떤 정보는 지금의 판단에 바로 영향을 주고, 어떤 정보는 상품의 성격을 천천히 학습시키며, 어떤 정보는 필요할 때만 찾으면 된다.

그래서 화면은 데이터의 양이 아니라 판단 순서에 맞춰 다시 배치됐다.

사용자 유형
→ 투자 목적
→ 지금 판단에 필요한 정보
→ 정보 우선순위
→ 화면 구조

ETF 아이콘의 색도 장식으로 끝내고 싶지 않았다. 레버리지는 빨강, 인버스는 파랑, 배당은 노랑처럼 색을 반복적으로 노출해 상품의 성격을 빠르게 구분하게 했다. 아이콘 하나가 상품의 모든 것을 설명하지는 않는다. 다만 사용자가 다음번에 더 빨리 판단할 수 있도록 작은 분류 언어를 만든다.

그때 내가 설계한 것은 사용자의 머릿속을 직접 설계하는 일이 아니었다. 대신 사용자가 무엇을 먼저 보게 되는지, 무엇을 같은 범주로 묶는지, 어떤 단서를 반복해서 학습하는지를 설계했다. “인지구조 설계는 맞긴 함”이라는 말은 그 작업에 뒤늦게 붙인 이름이다.

UI에서 문서로, 문서에서 언어로

Context Engine을 만들 때 대상만 바뀌었다. 이번에는 버튼이나 ETF가 아니라 금융 기사였다.

키워드 빈도가 높은 문서가 꼭 중요한 문서는 아니다. 사람은 문서를 읽을 때 단어를 세지 않는다. 누가 어떤 주장을 했는지, 그 주장에 어떤 근거가 붙는지, 지금의 결론이 이전 기사와 어떻게 이어지는지를 본다.

그래서 문서를 다음처럼 다루려 했다.

Article
→ Context
→ Claim
→ Evidence
→ Keyword
→ Related Article

원문을 한 번 요약하고, 다시 요약하고, 키워드로 압축한 이유도 같다. 짧게 만들기 위해서만은 아니었다. 문서의 표면을 줄여서 사람이 검토할 수 있는 의미 단위로 만들고, 그 단위들이 다른 기사와 어떻게 이어지는지 보려고 했다.

NLU와 VOC를 다룰 때는 이 계층이 더 노골적으로 필요했다. 문장 하나를 곧바로 이슈나 의도로 바꾸면, 관찰된 사실과 추론된 원인, 명시된 주장과 약한 후보가 한데 섞인다.

Sentence
→ Evidence
→ Observed Issue
→ Causal Issue
→ Business Topic

Utterance
→ Dialogue Act
→ Intent
→ Action

여기서 중요한 것은 분류표를 멋지게 만드는 일이 아니다. 판단이 어디에서 왔는지, 그 판단이 명시적인지 추론인지, 틀렸을 때 무엇을 고쳐야 하는지를 남기는 일이다. 나중에 사람과 시스템이 같은 오류를 보고 고칠 수 있으려면, 이 구분이 없어서는 안 된다.

Agent UX에서 다시 같은 문제가 나온다

요즘 Agent UI는 종종 생각 중이라는 문구, 도구 호출, 성공과 실패를 보여준다. 작업이 진행되고 있다는 사실은 보인다. 그런데 사용자가 알고 싶은 것은 로그가 아니다.

사용자는 지금 이 Agent가 무엇을 상황으로 이해하는지 알고 싶다. 어떤 목표를 잡았는지. 현재 계획이 무엇인지. 어떤 근거를 썼는지. 무엇이 불확실한지. 다음 행동이 무엇인지. 그리고 언제 내가 끼어들어야 하는지.

Task Visibility
≠
Cognitive Transparency

이 차이는 “설명을 더 많이 보여주자”로 풀 수 없다. 모든 tool trace와 추론 흔적을 화면에 올리면 사람이 더 잘 이해하는 것이 아니라, 새 로그 더미 하나를 받게 된다.

Situation Awareness 연구는 이 문제를 현재 상태, 그 상태의 의미, 앞으로의 전개라는 세 층으로 다뤄 왔다. Endsley의 모델을 Agent UX에 옮기면, 사용자가 필요한 것은 다음처럼 재구성할 수 있다.

Situation: 지금 무엇을 목표로, 어디까지 확인했는가
Why: 어떤 근거·가정·제약 때문에 이 경로를 택했는가
What next: 다음 행동과 그 위험, 다른 선택지는 무엇인가
My role: 여기서 나는 승인·수정·중단 중 무엇을 할 수 있는가

Agent transparency 연구도 단순한 상태 표시보다 상태, 이유, 예측을 구분해 보여줄 때 상황 인식과 신뢰 보정에 도움이 될 가능성을 보여준다. 다만 이 결과를 LLM Agent에 그대로 옮길 수는 없다. 실험의 과업과 환경이 다르다. 여기서 내가 가져오는 것은 확정된 해답이 아니라, 무엇을 비교 실험해야 하는지에 대한 설계 가설이다.

내부 상태를 사용자 상태로 번역하는 층

그래서 내가 정리한 Cognitive UX의 구조는 다음과 같다.

Raw Agent State
Goal · Memory · Plan · Tool · Observation
        ↓
Semantic Layer
Evidence · Assumption · Alternative · Risk · Provenance
        ↓
Mental Model Layer
Current situation · Why · What next · My role
        ↓
Interaction Layer
Continue · Approve · Correct · Interrupt

디자인 시스템에서 semantic token은 #4285F4라는 값과 primary라는 역할을 분리했다. Agent UX의 semantic layer도 비슷한 역할을 한다. 내부 이벤트 하나를 그대로 내보내는 대신, 그것이 사용자 판단에서 어떤 의미를 갖는지 연결한다.

예를 들어 “검색 도구를 두 번 호출했다”는 상태는 사용자에게 별 의미가 없다. “핵심 근거 두 개가 서로 상충한다. 지금의 결론은 보류하고, 범위를 좁혀 다시 검증하려 한다”는 상태는 다르다. 사용자는 그때 Agent를 계속 시킬지, 근거를 바꿀지, 작업을 멈출지 판단할 수 있다.

불확실성도 confidence 72% 하나로 끝내면 안 된다. 그 수치가 무엇에 대해 보정됐는지 모르면 신뢰의 근거가 아니라 분위기가 된다. 사용자에게 필요한 것은 근거가 부족한지, 출처가 상충하는지, 범위를 벗어난 추정인지, 검증이 아직 끝나지 않았는지다. 숫자보다 원인과 영향, 그리고 가능한 수정 경로가 먼저다.

사람의 개입도 모든 tool call 앞에 승인 버튼을 붙이는 일이 아니다. 비가역적 행동, 권한 경계의 변화, 목표나 범위의 변경, 근거 무효화처럼 사람의 판단 비용이 적절한 순간에만 넘겨져야 한다. Amershi et al.의 Human-AI Interaction 지침이 강조한 실패 가능성의 전달, 효율적인 수정과 취소, 맥락에 맞는 시점은 이 문제를 UI 부품이 아니라 운영 규칙으로 보게 한다.

좋은 Agent UX는 사람의 신뢰를 무조건 높이지 않는다. 믿어도 되는 때와 멈춰야 하는 때를 구분할 수 있게 만든다. 신뢰를 만드는 것이 아니라 신뢰를 보정하는 일이다.

로그가 늘어도 상황은 보이지 않는다

여기서부터는 직관만으로 말하고 싶지 않았다. 그래서 Situation Awareness와 human-agent transparency 연구를 다시 읽었다. Endsley는 동적인 환경을 이해하는 일을 현재의 요소를 알아차리는 단계, 그 의미를 이해하는 단계, 다음 상태를 예상하는 단계로 나눴다. Agent UX에 그대로 대입하면 tool running은 첫 단계의 아주 작은 조각일 뿐이다. 사용자는 도구가 돌아간다는 사실만이 아니라, 그 실행이 목표에 어떤 의미를 갖는지와 다음에 어떤 결과를 낳을지를 알아야 한다.

Selkowitz, Lakhmani, Chen의 2017년 실험은 이 구분을 Agent display에 적용했다. 60명이 자율 로봇을 감시하는 과업에서 현재 상태만 보여 주는 조건보다, 상태와 reasoning, 미래 상태와 uncertainty를 함께 제공한 조건에서 상황 인식과 trust가 높게 나타났다. 이 결과만으로 LLM Agent 화면의 정답이 나왔다고 말할 수는 없다. 로봇 감시와 열린 지식 작업은 다르다. 그래도 무엇을 비교해야 하는지에는 선을 그어 준다. 상태, 이유, 예측을 하나의 로그에 섞지 말 것.

그 차이는 생각보다 실무적이다. “웹 검색을 두 번 실행했다”는 관찰이다. “두 출처가 시장 규모를 다르게 정의해 결론을 보류했고, 범위를 국내 상장 ETF로 좁혀 다시 확인한다”는 상황 설명이다. 전자는 Agent의 활동 기록이고, 후자는 사람이 계획을 이해하고 고칠 수 있는 상태다.

모든 정보를 동시에 보여 주라는 뜻도 아니다. Daronnat 등은 180명 조건 비교에서 상황 인식 정보 수준과 설명 형식에 따라 수행, trust, cognitive load가 다르게 움직인다고 보고했다. 투명성의 최적량은 고정된 값이 아니다. Gruber 등의 lifecycle transparency 연구에서도 trust 차이가 일관되게 나타나지 않았다. 설명은 많을수록 좋은 기능이 아니라, 과업과 시점에 맞춰 설계해야 하는 환경이다.

그래서 기본 화면은 현재 goal, 확인된 사실, 다음 행동, 핵심 risk까지만 붙잡아야 한다고 본다. 근거의 출처, 가정, 제약, 기각한 대안은 사용자가 “왜?”를 물을 때 열리게 한다. 모든 분기와 모든 tool event를 미리 펼치는 화면은 투명한 화면이 아니라, 읽을 수 없는 화면이 되기 쉽다.

신뢰의 문제는 확신의 문제가 아니다

Agent가 confidence 72%라고 말할 때, 사용자는 그 숫자를 신뢰도처럼 읽기 쉽다. 그러나 confidence는 근거의 품질도 아니고, 실제 정확도 확률도 아니다. Guo 등의 calibration 연구가 보여주듯, 모델의 confidence를 정확도와 맞추는 일 자체가 별도의 문제다. 보정 근거가 없다면 퍼센트는 판단을 돕는 신호가 아니라 과신을 부르는 분위기가 된다.

그래서 불확실성을 하나의 숫자로 처리하지 않으려 한다. 지금의 결론이 약한 이유가 근거 부족인지, 출처 상충인지, 적용 범위를 벗어난 추정인지, 아직 검증이 끝나지 않았는지 보여야 한다. 여기에 대안과 전환 조건까지 붙어야 사용자가 다음 행동을 고를 수 있다.

현재 결론
├─ 어떤 근거가 직접 지지하는가
├─ 무엇이 아직 확인되지 않았는가
├─ 어떤 출처가 서로 충돌하는가
├─ 다른 경로를 택하면 무엇이 달라지는가
└─ 어느 조건에서 계획을 바꿀 것인가

생성형 시스템의 인용도 이 문제를 잘 보여 준다. Liu, Zhang, Liang의 2023년 평가는 네 시스템이 만든 문장 가운데 인용으로 완전히 뒷받침된 비율이 평균 51.5%였고, 인용과 문장의 정합률은 74.5%였다고 보고했다. 링크 하나가 있다고 해서 그 문장이 근거를 갖는 것은 아니다. Agent의 evidence card도 claim → source span 또는 tool result → 시점 → 직접성 → 검증 상태를 따라가야 한다. 그래야 사용자가 “출처가 있네”에서 멈추지 않고 “이 출처가 이 주장까지 실제로 지지하나”를 판단할 수 있다.

이것이 Explainable AI와 Cognitive UX의 차이라고 생각한다. 설명은 대개 답이 나온 뒤 이유를 붙이는 일로 취급된다. Cognitive UX에서 근거와 불확실성은 사후 해설이 아니라, 사람이 계속할지 고칠지 멈출지를 결정하게 하는 현재 상태다.

개입은 승인창이 아니라 handoff다

Human-in-the-loop을 모든 tool call 앞의 승인 버튼으로 이해하면, 사람은 곧 Agent의 속도를 늦추는 병목이 된다. 반대로 사람을 완전히 빼면, 목표와 위험이 바뀌는 순간에도 Agent는 이미 낡은 전제 위에서 달린다.

중요한 것은 승인 횟수가 아니라 판단권이 넘어가는 조건이다. NIST AI RMF는 human-AI configuration의 자율성 수준이 맥락마다 다르며, 감독과 의사결정 역할을 명확히 해야 한다고 권고한다. Mixed-initiative UAV 연구에서 자원 탈락 뒤 자동 재계획을 사람이 검토하고 수정하고 실행하게 한 방식은, 수동 방식보다 재계획 성과와 workload에 이점이 있었다. 이 역시 지식 작업 Agent의 효과를 보장하지는 않는다. 다만 사람의 개입을 예외 처리로 밀어 넣는 대신, 시스템의 계획 변경을 함께 다루는 handoff로 봐야 한다는 근거가 된다.

Agent가 사람을 불러야 하는 순간은 꽤 구체적이다. 비가역적 행동을 앞두고 있을 때. 권한의 경계를 넘을 때. 목표나 범위가 처음 합의한 것과 달라질 때. 핵심 근거가 무효화됐을 때. 도구나 의존성이 실패했을 때. 대안들 사이의 손실이 커져 가치 판단이 필요할 때다.

그때 UI가 해야 할 일은 “승인하시겠습니까?”를 띄우는 것이 아니다. 무엇이 바뀌었는지, 왜 바뀌었는지, 그 영향이 무엇인지, Agent가 제안하는 re-plan이 무엇인지를 한 번에 보여 주고 approve, edit, reject, defer, interrupt 중 무엇을 할 수 있는지 밝혀야 한다. 긴급하지 않은 요청을 subtask 끝이나 plan checkpoint에 모으는 것도 중요하다. 사람의 주의는 시스템의 불규칙한 속도에 맞춰 무한히 전환되지 않는다.

기억은 보이지 않는 컨텍스트로 두지 않는다

Memory에서도 같은 문제가 반복된다. Agent가 무엇을 기억하고 있는지 모르면, 사용자는 답변을 고쳐도 다음 행동이 왜 바뀌거나 바뀌지 않는지 알 수 없다. 기억을 단순한 context buffer로 두면, 사람은 자신이 어떤 사실을 수정해야 하는지조차 찾기 어렵다.

Memory Sandbox 연구는 사용자가 memory object를 표시하고 숨기고, 추가하고 수정하고 삭제하고 요약하며 대화 사이에 공유할 수 있게 설계했다. 이 접근이 흥미로운 이유는 기억을 더 잘 저장하는 기능으로 다루지 않았기 때문이다. Agent의 기억과 사용자의 이해를 맞추는 공유 표현으로 다뤘다.

그래서 memory card에는 내용만 있으면 안 된다. 이 기억은 어디서 왔는지. 어느 범위에서만 유효한지. 언제 기록되고 수정됐는지. 지금의 plan이나 response에 실제로 쓰였는지. 검증되었는지. 사용자가 이를 correct, exclude, forget, reprioritize할 수 있는지가 함께 있어야 한다.

여기서 ontology와 semantic layer의 역할도 달라진다. 예쁜 지식 그래프를 그리기 위한 층이 아니다. 어떤 Decision이 어떤 Evidence와 Memory를 사용했는지, 어떤 Memory가 어느 Source에서 나왔는지, 무엇이 무효화됐는지를 추적하고 검증하는 층이다. PROV-O의 생성·사용·파생·귀속 관계와 SHACL의 구조 검증은 이 경로가 비어 있거나 깨졌을 때 시스템이 그냥 지나가지 않게 한다. 출처 없는 고위험 결정, 이미 무효화된 기억의 재사용, 누가 언제 고쳤는지 없는 correction은 모두 사람에게 보여 줄 개입 신호가 될 수 있다.

다만 기본 화면에 전체 그래프를 띄울 필요는 없다. 사용자가 보는 것은 지금의 response나 plan에 실제 영향을 준 local provenance path면 충분하다. 전체 history와 주변 관계는 필요할 때만 펼친다. 디자인 시스템에서 모든 토큰의 참조망을 버튼 옆에 보여 주지 않는 것과 같다. 지금의 결정을 이해할 만큼만 보이고, 질문이 생기면 관계를 따라 들어갈 수 있게 만든다.

다음에 검증할 것은 화면의 만족도가 아니다

이 연구가 지금 제공하는 것은 완성된 UI 원칙이 아니라 prototype의 비교 기준이다. chat/tool log만 보이는 조건, 현재 상황과 다음 행동을 담은 situation card 조건, 근거·가정·대안·memory·intervention을 연결한 cognitive graph 조건을 같은 과업에서 비교할 수 있다.

이때 trust 설문 하나로 끝내면 안 된다. 사용자가 Agent와 같은 상태를 얼마나 정확히 재구성하는지. 올바른 권고는 받아들이고 잘못된 권고는 거절하는지. 필요한 순간에 얼마나 빨리, 그리고 제대로 개입하는지. 근거의 출처를 찾는지. 이미 무효화된 memory를 다시 쓰지 않는지. NASA-TLX로 작업 부담이 어떻게 달라지는지까지 봐야 한다.

좋은 화면이라는 감상보다 어려운 기준이다. 대신 Agent UX가 정말로 사람과 Agent의 Shared Situation Awareness를 만들었는지, 아니면 그럴듯한 진행 화면 하나를 추가했는지를 가를 수 있다.

나는 디자인을 떠난 것이 아니다

돌아보면 색을 다루다가 색공간과 수학으로 내려갔다. 언어를 다루다가 형태소와 화행으로 내려갔다. Agent를 다루면서는 Memory, Ontology, State, Loop로 내려가고 있다.

주변에서는 가끔 “그렇게까지 했다고?”라고 묻는다. 나는 늘 그렇게까지 해야만 했다고 답하게 된다. 과장을 위해 바닥까지 내려간 것이 아니다. 화면에서만 풀리지 않는 문제가 있으면, 그 화면이 의존하는 개념과 데이터와 규칙까지 내려가야 다시 올라올 수 있었기 때문이다.

그래서 나는 디자인을 하다가 AI로 넘어온 것이 아니다. 색과 아이콘에서 시작해 컴포넌트와 정보 구조로, 문서의 문맥과 언어의 판단으로, 이제 Agent의 목표와 근거와 개입 지점으로 다루는 대상을 넓혀 왔다.

계속 남아 있던 질문은 하나다.

사람이 이해하는 개념과 관계를 어떻게 시스템이 처리할 수 있는 구조로 만들고, 다시 사람이 직관적으로 이해할 수 있는 인터페이스로 돌려줄 것인가.

UI는 Agent 시스템의 마지막 장식이 아니다. 사람과 Agent가 같은 상황을 놓고 서로의 판단을 교정할 수 있게 만드는 인지 인터페이스다.

나는 그 UI 단에서부터 Agentic AI를 풀어보고 싶다. 우선은 그것이 실제로 사람의 상황 이해와 개입 시간을 바꾸는지, 만들고 비교해서 확인해야 한다.

참고

• Endsley (1995), Toward a Theory of Situation Awareness in Dynamic Systems

• Selkowitz, Lakhmani, & Chen (2017), Using agent transparency to support situation awareness

• Daronnat, Azzopardi, & Halvey (2022), Comparing levels and types of situational awareness-based agent transparency

• Gruber et al. (2024), Examining the Impact of Transparency on Human-Autonomy Teaming

• Mercado et al. (2016), Intelligent Agent Transparency in Human-Agent Teaming

• Amershi et al. (2019), Guidelines for Human-AI Interaction

• Guo et al. (2017), On Calibration of Modern Neural Networks

• Liu, Zhang, & Liang (2023), Evaluating Verifiability in Generative Search Engines

• NIST AI Risk Management Framework 1.0

• Ramchurn et al. (2015), Human-agent collaboration for disaster response

• Huang et al. (2023), Memory Sandbox

• W3C PROV-O · W3C SHACL