Making agentic workflows trustworthy and verifiable with a custom DSL

출처 https://youtu.be/qOjleN2-50c · 채널 Claude (Anthropic) · 길이 00:29:39 포맷 “Code with Claude” 컨퍼런스 발표. Elicit의 Head of Engineering James Brady가 슬라이드로 개념(신뢰·desiderata·언어 설계)을 설명한 뒤, elicit.com 실제 세션을 라이브 데모하며 “테이블 아티팩트 ↔ 그 뒤의 실행 가능한 DSL 코드”를 오가며 보여준다. 같은 컨퍼런스의 “Building the future of agentic infrastructure” 좌담과 짝을 이루는, 에이전트 하네스 설계의 실전 사례다. 원본 자막: raw/transcripts/2026-07-12-elicit-aepl-verifiable-agentic-workflows.en.srt (자동 생성 자막이라 회사명이 “Alissa”, DSL명이 “Ash PL”로 오인식됨 — 실제로는 Elicit / ÆPL)

한눈에 보는 요약

• 핵심 주장: “메커니즘이 중요하다(Mechanism matters)”. 두 시스템이 완전히 똑같은 출력을 내놓아도, 그 답을 어떻게 만들었는지에 따라 신뢰도는 전혀 달라진다. “이 코드는 보안 취약점이 없다”는 같은 문장이라도, 구형 모델이 한 번에 뱉은 것과 최신 모델이 도구·비평·재작성을 거쳐 낸 것은 근본적으로 다른 물건이다.
• Elicit이 자기 리서치 에이전트에 세운 3가지 조건(desiderata): ① 에이전트의 과정이 읽을 수 있어야(legible) 한다 — 사람도, 다른 에이전트(비평 에이전트)도 점검 가능. ② 과정을 반복·수정해도 원래 의도가 흐트러지지 않아야(retains fidelity) 한다 — 층을 쌓다 보면 모델이 방향을 잃고 “처음부터 다시”가 되는 드리프트를 막아야 함. ③ 정해진 과정이 실제로 그대로 실행되어야(followed faithfully) 한다.
• 해법: ÆPL이라는 커스텀 DSL. 이 세 조건이 자연스럽게 DSL로 이끌었다. ÆPL은 튜링 불완전(루프·재귀·변이 없음), 순수 함수형, 반응형(reactive), 그리고 Python의 “의견 있는 부분집합” — Python을 무작위로 깎은 게 아니라, 안 쓰는 기능은 빼고 도메인(학술 논문·임상시험 검색 등) 전용 프리미티브를 더한 것.
• 동작의 심장 = 작성 → 해석 → 재작성 루프. Curator(Claude가 맡는 컴포넌트)가 ÆPL을 쓰면, Python 서비스가 파싱·타입체크 후 해석한다. 타입 에러가 나면 “52번 줄 고쳐” 하고 싸게 되돌려보내고, 성공하면 결과를 받아 프로그램 전체를 다시 쓰고 다시 처음부터 전체 해석한다.
• 매번 전체를 재해석해도 빠른 비결 = 콘텐츠 주소화 저장소(content-addressed store). 순수 함수형 언어라 표현식을 해시해 캐싱(memoization)할 수 있다. 이미 계산한 웹/논문 검색은 해시로 즉시 꺼내 쓴다. “일부 조각만 해석”하지 않고 전체를 매번 통짜로 재해석하는 이유는, 그래야 응집성·정합성에 대해 통계적 보증을 하기 쉽고 드리프트가 끼어들 틈이 없기 때문.
• 왜 이렇게까지? 데모의 테이블(생물학 파운데이션 모델 투자 지형도)은 최신 모델이 그냥 뱉어도 겉보기엔 비슷할 수 있다. 하지만 Elicit은 그 테이블을 만드는 과정 자체를 사용자에게 읽기 좋은 형태(ÆPL 코드 + 그래프 뷰)로 노출하기 때문에, 사용자에게 그 둘은 근본적으로 다른 신뢰도의 물건이 된다. “DSL을 쓰라”가 아니라 “메커니즘을 신경 쓰라”가 발표의 진짜 메시지.

---

장면별 상세 설명

[00:15] 1. 인트로 — James Brady, Elicit

발표자는 Elicit의 Head of Engineering James Brady. 오늘 주제는 “커스텀 DSL로 에이전트 워크플로우를 신뢰할 수 있고 검증 가능하게 만드는 법”이다. 순서는 ① 왜 애초에 DSL을 택했는지 → ② 언어 자체와 설계 결정 → ③ Elicit에 어떻게 통합했는지 → ④ 라이브 데모 → ⑤ 마무리.

[00:26] 2. 오늘의 구성 (Agenda)

목차 7개: Mechanism matters → Our desiderata → ÆPL(커스텀 DSL) → How Elicit works → Demo → What you’d need to build → Takeaway. 이 노트도 대체로 이 흐름을 따른다.

[00:50] 3. 두 시스템이 똑같은 출력을 낸다면 — “Mechanism matters”

발표를 여는 질문: “두 시스템이 완전히 동일한 출력을 낸다. 당신은 둘을 똑같이 신뢰하는가?” 답은 “경우에 따라 다르다” — 그 출력을 만들기까지 시스템 안에서 무슨 일이 있었는지에 달렸다.

구체적 예: 정적 분석 도구가 한참 돌더니 “이 코드는 보안 취약점이 없으니 배포해도 안전”이라고 말한다. 그런데 그게 구형 모델(예: 3.5급) 한 방으로 나온 결과라면? 반대로 최신 SOTA 모델이 온갖 도구를 쓰고, 비평(critique)하고, 재작성(redraft)까지 거쳐 낸 결과라면? 메시지는 글자 그대로 똑같아도 우리는 두 메시지에 전혀 다르게 반응한다. 그래서 “어떻게(how)“가 최종 출력만큼, 그러나 다른 방식으로 중요하다.

단, 올바른 메커니즘이 하나로 정해져 있는 건 아니다. 이건 설계 선택이고, 도메인·사용자·과제에 따라 달라진다. 특히 속도 vs 엄밀함(rigor)의 트레이드오프가 있다 — 깊고 방어적이고 고품질인 작업은 자연히 오래 걸린다. Elicit은 **신뢰성·고품질·데이터 출처(provenance)**를 브랜드로 삼기에, 결과 뒤에 확실히 서 있고 싶어 한다. 그 지향이 다음의 3가지 조건으로 응축된다.

[03:21] 4. Elicit 리서치 에이전트의 3가지 조건 (desiderata)

• ① 과정이 읽을 수 있어야 한다(legible). 사람이 훑어볼(spot-check) 수 있어야 할 뿐 아니라 다른 에이전트도 읽을 수 있어야 한다 — 비평 에이전트를 그 위에 돌릴 수 있도록.
• ② 과정을 반복·수정해도 원래 의도의 충실도가 유지되어야 한다(retains fidelity). 발표자가 겪은(그리고 청중도 겪었을) 현상 — 작업물을 다듬으며 “이건 좀 아니고, 이 방향으로, 이 고려사항도 추가…” 하다 보면 처음 의도에서 조금씩 드리프트하고, 모델이 헷갈려 결국 “처음부터 다시 하자”가 된다. 이건 신뢰를 해친다. 우리는 명료함·일관성을 잃지 않으면서 층을 더하고 방향을 틀 수 있길 원한다.
• ③ 정해진 과정이 실제로 그대로 실행되어야 한다(followed faithfully). 읽을 수 있게 만들고 사용자가 확인까지 했는데, 시스템이 정작 그 단계들을 안 밟는다면 무의미하다.

Brady는 못박는다 — “모두가 DSL을 써야 한다는 말이 아니다.” 다만 이 세 조건이 Elicit에겐 자연스럽게 DSL로 이어졌다.

[05:41] 5. ÆPL — 에이전트 워크플로우를 위한 우리의 DSL

DSL의 이름은 ÆPL. 앞의 Æ 합자(ligature)는 고대 영어 이중음자로 “Ash”라고 읽어서, 자동 자막이 “Ash PL”로 받아썼다. Elicit 제품의 에이전트 워크플로우를 담당하는 도메인 특화 언어다.

[06:10] 6. ÆPL의 구별되는 특징

• 튜링 불완전(Turing-incomplete). 루프도, 재귀도, 변이(mutation)도 없다. 상대적으로 단순.
• 순수 함수형(Purely functional).
• 반응형(Reactive).
• Python의 “의견 있는 부분집합”(opinionated subset). 여기서 “opinionated”가 핵심 — Python을 아무 데나 조금 깎은 게 아니라, 별로 도움 안 되는 언어 기능은 빼고, 도메인 전용 프리미티브를 더했다. Elicit의 도메인은 과학 리서치와 고위험 실증적 의사결정이라, 학술 논문 검색·임상시험 조회 같은 것이 언어에 내장돼 있다.

[07:08] 7. ÆPL 코드 예시 + 작성·해석·재작성 루프

오른쪽 코드는 Python처럼 보인다 — ÆPL이 Python의 부분집합이기 때문. 타입이 붙어 있어서(typed) 타입 에러가 나면 빠르게 재작성할 수 있다. 이 예시 프로그램은 “Elicit 자신의 경쟁 분석”을 하려던 과정이다: 다른 학술 검색 엔진·AI 어시스턴트·체계적 문헌고찰 도구를 웹에서 찾고(agentic_web_retrieval), 결과를 합치고(join), 소스를 보강(get_full_text_many)하고, 경쟁사 정보를 추출(map(extract_competitor_info, …))한 뒤, 중복 제거 프롬프트로 통합한다.

핵심 엔진은 이 루프다: Curator 컴포넌트가 ÆPL을 쓰고(write) → Python 코드로 **해석(interpret)**하고 → 방금 일어난 일을 바탕으로 **재작성(redraft)**한다. 단순 케이스: 코드를 썼는데 타입 에러 → Curator로 되돌아가 수정 → 재해석 → 이번엔 실행 → 결과 도착 → 다시 재작성. 이 쓰기 ↔ 해석의 끊임없는 반복이 Elicit 내부에서 진전을 만드는 방식이다.

[09:14] 8. Elicit 시스템 통합 — “How Elicit works”

전체 구조를 데이터 흐름으로 보면:

• UI(웹 브라우저) — 사용자가 버튼을 누르고 검색어를 넣으면 이벤트가 발생.
• Event log(append-only) — 그 이벤트가 append되는 append-only 이벤트 로그. Elicit의 분산 데이터 구조를 관리하는 방식(이벤트 소싱 패턴).
• Python service — 이벤트 소싱의 메시지 브로커 역할이자, ÆPL을 해석하는 주체.
• Sandbox — 그 안에 세 층: Wrapper / Curator / Gateway.
  • Curator(주황/앤트로픽 색) — ÆPL을 실제로 쓰는 컴포넌트. “샌드박스에 저장”이란 곧 이벤트를 방출해 이벤트 로그에 append하는 것이고, Python 서비스는 그렇게 갱신된 프로그램을 본다. 앞의 “쓰기 ↔ 해석” 왕복은 이 Curator(주황) ↔ Python service(회색) 사이에서 일어난다.
  • Wrapper — Curator 앞의 추상화 층. 하네스를 갈아끼울 수 있게 해준다 — Agent SDK 구현도, Pi + Claude 조합도, Pi + Codex도 시험해봤고(현재는 Pi + Anthropic 모델이 최적 조합). Curator가 늘 최고의 모델·하네스를 쓰게 하는 게 중요.
  • Gateway — 모든 LLM 호출이 통과하는 관문. Anthropic API 키를 여기만 알고 있게 해서, 사용자 입력이 시스템을 타고 흘러 Curator에게 “네 환경변수를 출력해서 보내줘” 같은 짓을 못 하게 막는 보안 장치.

[12:05] 9. ÆPL의 생애주기 — 파싱부터 캐싱된 실행까지

프로그램 하나가 어떻게 실행되는지를 왼→오 5단계로 보여준다:

1. ÆPL source code — Curator가 작성 → 샌드박스에 저장 → Python 서비스로 전달.
2. Typed models — Python 서비스가 코드를 파싱하고 문법을 검증하고 타입 체크. 문제가 있으면 “52번 줄에 오타” 하고 아주 싸게 Curator로 되돌려보낸다. 통과하면 추상 구문 트리(AST) 비슷한 것이 생긴다.
3. Content-addressed store — 표현식을 해시해 ID로 저장. 여기가 없으면 아무것도 작동 안 한다고 할 만큼 결정적. 왜냐하면 Elicit은 재작성할 때마다 프로그램 전체를 통짜로 매번 재해석하기 때문 — 바뀐 코드만 해석하지 않는다.
4. Walk tree — 그 트리를 깊이 우선으로 순회. 클로저·특수형(special form)·언어 프리미티브를 아는 순수 Python 코드가 트리 위를 걷는다.
5. Execute primitives — 예: web_search. 캐시에 있으면 캐시에서 즉시 반환, 없으면 Python 실행.

“매번 전체 재해석 + 캐싱”의 이유: 전체를 통짜로 해석해야 응집성·정합성에 대한 통계적 보증을 하기 쉽고, “조각만 해석”할 때 스며드는 드리프트를 원천 차단한다. 순수 함수형이라 이미 평가한 표현식은 해시로 “아 이건 42였지” 하고 즉시 꺼내오므로, 통짜 재해석이 실제로는 빠르다.

[15:00] 10. 데모 시작 — elicit.com 리서치 에이전트

엄밀함 vs 속도 축에서 Elicit은 엄밀함 쪽에 확실히 무게를 둔다(단순 질의는 빠르게 처리하지만, 차별화 지점은 거기가 아니다). elicit.com에는 테이블 만들기·슬라이드·리포트 초안 같은 템플릿이 있고, 데모로는 research landscape를 고른다. 실제 세션은 몇 시간에 걸쳐 층을 쌓아 만든 것이라, 미리 저장해둔 세션을 연다.

[16:28] 11. 첫 분석 단계 — 12개 검색, 120편 스크리닝

세션 주제는 “생물학용 파운데이션 모델에 투자하는 기업·기관 지도 그리기”. 첫 단계에서 Elicit이 먼저 되물었다 — “넓은 지형도인지, 특정 파운데이션 모델인지, 학술기관 위주인지 기업 위주인지?” 사용자가 “넓은 지형도”라고 답하자, 이후 단계는 전부 ÆPL이 몰고 간다.

이 첫 분석 블록은 학술 논문 검색(genomic foundation model pretraining transformer 등)과 웹 검색을 여러 개 돌리고, 가능하면 논문 전문을 가져오고, 스크리닝(필터링)한다 — 12개 검색, 120편 전문 스크리닝. 이 모든 단계가 ÆPL로 인코딩돼 있으며, ÆPL은 계획의 표현이 아니라 실행 가능한 계획 그 자체다. 그래서 “말한 대로 계획을 따랐다”를 확신할 수 있다.

[17:44] 12. 결과 아티팩트 — 조직별 파운데이션 모델 테이블

한참의 처리와 상당한 토큰 끝에 이런 테이블(Elicit은 아티팩트라 부름)이 나온다. 각 행은 생물학 파운데이션 모델에 관심 있는 조직이고, 열로는 조직 유형·본사·파운데이션 모델·모달리티·투자/펀딩·주목할 협업이 함께 추출돼 있다 — Google DeepMind(AlphaFold 3), Meta AI(FAIR)(ESM-2/ESMFold), Microsoft Research(HybriDNA/NatureLM), NVIDIA(BioNeMo) 등.

[18:45] 13. 아티팩트 뒤의 실행 가능한 ÆPL 코드

“이게 ÆPL로 만들어졌다는 걸 어떻게 아나?” — 각 아티팩트마다 그것을 생성한 ÆPL 코드를 그대로 열어볼 수 있다. 위 테이블 뒤의 코드는 이렇게 시작한다:

# Phase 1: Broad Discovery of Bio Foundation Model Players
# Goal: High-recall list of companies + academic institutions building foundation models for biology.
 
def run_web_search(q: str) -> Sequence[EnrichedSource]:
    return exa_web_search(prompt=q, max_results=15)
 
def run_paper_search(q: str) -> Sequence[Source]:
    return elicit_paper_search(query=q, max_results=30)
 
web_queries: Sequence[str] = [
    "foundation models for biology companies startups 2024 2025",
    "protein language model companies ESM AlphaFold competitors",
    "DNA genomic foundation model companies Evo Nucleotide Transformer",
    ...
]
academic_queries: Sequence[str] = [ ... ]

솔직히 ÆPL을 들여다보는 게 재밌는 일은 아니다 — 대부분의 사용자는 안 본다. 이걸 두는 이유는 시스템이 우리가 정한 지시를 따르고 있음을 알기 위해서다. 그리고 다른 에이전트가 이 ÆPL을 읽고 “여기 빠진 검색이 있다, 사용자 질의의 이 부분을 놓쳤다”고 지적할 수 있다 — 계획이 이렇게 읽기 좋을 때 특히 유용하다.

[20:07] 14. 사용자용 그래프 뷰 — ÆPL에서 직접 파생

코드보다 사용자에게 친절한 건 그래픽 표현이다. 이건 예쁘게 지어낸 시각화가 아니라 계획이 실행한 바로 그 ÆPL에서 직접 파생된 것 — 검색 몇 개로 시작해 보강(enrichment, 논문 전문 가져오기)·추출·큐레이션(필터링)·추가 검색으로 이어지는 흐름이 노드로 그려진다. Brady는 “내가 이 과정을 지지(endorse)할지 스스로 납득하려 할 때 이 뷰가 실제로 유용하다 — 뭔가 어긋난(skewiff) 지점이 금방 눈에 띈다”고 말한다. 물론 여기서 멈추지 않고 다른 층의 조사를 더 얹을 수 있다.

[22:11] 15. 층 쌓기 + 조인 — 그리고 동일 프리픽스 캐싱

Brady는 세션에 층을 계속 더한다 — 오픈소스 vs 클로즈드소스 전략 비교, 상용화(GTM) 전략, 정부·감독 기관 매핑. 그리고 마지막에 자연어로 “이 둘을 조인하고 싶다”(조직 테이블 × 감독기관 테이블)고 말하니, 랩들이 US AI Safety Institute·영국 AISI 등과 어떻게 상호작용했는지 보여주는 새 테이블이 나온다.

이 조인 테이블의 ÆPL을 보면 맨 위가 맨 처음 테이블의 코드와 글자 그대로 동일하다 — 같은 웹/논문 쿼리. 다른 점은 이제 프로그램이 훨씬 길다는 것(처음 ~100–150줄 → 약 1,000줄+). 마지막 테이블을 만드는 시점에 이 1,000줄 전체를 처음부터 다시 해석했지만, 위쪽은 이미 다 해둔 웹/논문 검색이라 캐시에서 대부분 즉시 나온다. “조각만 해석”했다면 드리프트가 끼어들 자리 — 전체를 매번 통짜로 해석하기에 응집성·정합성을 통계적으로 보증하기 쉽다는 설계 결정의 실물 증거다.

[25:14] 16. 만들어야 할 것들 — 8가지 체크리스트

DSL이 당신의 제품·조직 지향에 맞다면, 실제로 지어야 할 것들:

1. agent-ergonomic DSL 설계 — 학습 데이터에 예시가 많은 기존 언어를 바탕으로 하면 유리하다(모델=Curator가 문법을 새로 배울 필요 없이 “이 부분집합만 쓰면 돼”만 알면 됨). 정작 DSL 자체에 들어간 노력은 놀랄 만큼 적었고, 나머지 전부가 평범한 소프트웨어 엔지니어링이었다.
2. 하네스 무관 wrapper — 하네스·모델을 갈아끼우게 해주는 층.
3. 인터럽트 처리 — 결과를 기다리는 중 사용자가 채팅에 다른 걸 던지면, 세상을 멈추지 않고 Curator로 흘려보내 계획을 재작성하게. 어떤 하네스도 기본 제공하지 않아 직접 만들어야 함.
4. 세션 지속성(persistence) — 나중에 세션으로 돌아와 리하이드레이트(rehydrate). 역시 네이티브 기능이 아님.
5. 자격증명 격리(credential isolation) — 앞의 Gateway/wrapper 이야기(API 키 보호).
6. 모델이 뱉는 메시지 가로채기 — 메시지가 그냥 stdout으로 유실되지 않게. 모델을 많이 다뤄본 사람이라면 익숙한 성가심.
7. 분산 상태 관리 — Elicit은 이벤트 소싱을 쓴다(만족도 높지만 결코 작은 작업 아님).
8. 엄청난 양의 eval — 시스템이 프로그램을 즉석에서 쓰고 실행하니 평가가 매우 어렵다. Elicit엔 전담 eval 팀이 있고, 여기 시간을 많이 투자하라고 강력 권한다.

(Brady의 대략적 권고: 대부분은 3·4·5·6이 필요하고, 2는 추천, 1은 당연, 7은 뭐라도 해야 하고, 8은 필수.)

[28:03] 17. 결론 — DSL을 쓰라가 아니라, 메커니즘을 신경 쓰라

시작의 질문으로 되돌아온다. 데모의 그 테이블은 Opus가 그냥 뱉어도 겉보기엔 크게 이상하지 않을 수 있다(시간상 못 보여준 중요한 기능들이 더 있지만, 표면적으론 SOTA 모델이 낼 법하다). 그러나 Elicit은 그것을 아주 공들인 특정 과정으로 만들고, 그 과정을 ÆPL 코드와 그래프 뷰로 사용자에게 읽기 좋게 노출한다. 사용자들과의 대화로 확인하건대, 그들은 이 두 테이블을 전혀 다른 신뢰도의 물건으로 여긴다 — Elicit의 테이블은 모델이 그냥 뱉어낸 테이블과 근본적으로 다른 것이다.

“내 주장은 당신도 DSL을 쓰라는 게 아니다. 메커니즘을 많이 신경 쓰라는 것이다 — 메커니즘이 중요하기 때문에.”

핵심 개념·용어 메모

• Mechanism matters — 동일한 출력이라도 생성 과정이 신뢰도를 가른다. 올바른 메커니즘은 하나로 정해져 있지 않고 도메인·사용자·과제에 따른 설계 선택이며, 속도 vs 엄밀함의 트레이드오프를 동반한다.
• 3가지 desiderata — 과정이 ① 읽을 수 있고(legible; 사람 + 다른 에이전트) ② 반복·수정해도 원의도 충실도 유지(retains fidelity; 드리프트 방지) ③ 실제로 그대로 실행됨(followed faithfully). 이 셋이 DSL 선택을 자연스럽게 이끌었다.
• ÆPL — 튜링 불완전(루프·재귀·변이 없음) · 순수 함수형 · 반응형 · Python의 opinionated subset(불필요 기능 제거 + 도메인 프리미티브 추가: 학술 논문·임상시험 검색). 타입 있음 → 값싼 재작성.
• 작성 → 해석 → 재작성 루프 — Curator(Claude)가 ÆPL을 쓰고, Python 서비스가 파싱·타입체크·해석하고, 결과로 전체 프로그램을 재작성해 다시 통짜 재해석. Curator ↔ Python service 왕복이 진전의 심장.
• Content-addressed store(콘텐츠 주소화 저장소) — 순수 함수형이라 표현식을 해시해 memoize. “일부만 해석”하면 드리프트가 끼므로 매번 전체를 통짜 재해석하되, 캐시로 실제로는 빠르게. 응집성·정합성의 통계적 보증이 목적.
• ÆPL은 계획의 표현이 아니라 실행 가능한 계획 그 자체 — 그래서 “계획대로 실행됨”을 보증. 아티팩트마다 그것을 만든 ÆPL 코드와 ÆPL에서 직접 파생된 그래프 뷰를 열람 가능.
• 아키텍처 — UI → append-only Event log(이벤트 소싱) → Python service(브로커 + 해석기) → Sandbox(Wrapper: 하네스 교체 / Curator: ÆPL 작성 / Gateway: API 키 격리·보안) → Claude.
• DSL을 쓸 때 실제로 지어야 할 것 — wrapper·인터럽트 처리·세션 지속성·자격증명 격리·메시지 가로채기·분산 상태(이벤트 소싱)·막대한 eval. 정작 DSL 자체 노력은 의외로 적고 나머지가 대부분.

등장한 사람·조직·키워드

James Brady(Elicit, Head of Engineering), Elicit(elicit.com; 자막엔 “Alissa”), ÆPL(자막엔 “Ash PL”), Anthropic·Claude, Code with Claude(컨퍼런스). 기술 키워드: Turing-incomplete, 순수 함수형/reactive DSL, opinionated subset of Python, Curator, content-addressed store/memoization, event sourcing, append-only event log, harness wrapper, Pi(하네스), Agent SDK, Gateway/credential isolation. 데모 도메인: 생물학 파운데이션 모델(AlphaFold 3/GDM, ESM-2·ESMFold/Meta FAIR, HybriDNA·NatureLM/Microsoft Research, BioNeMo/NVIDIA), exa_web_search, elicit_paper_search.

원문 인용 모음

• [00:00:36] “Let’s say that two systems produce identical output. Do you trust them equally? And the answer is, of course, well, it depends. It depends on what went on inside of those systems to produce that output.”
• [00:01:08] “The mechanism, the how of how an answer is produced is as important — and important in a different way — compared to just the final output itself.”
• [00:05:28] “I’m not saying that everyone should be using a DSL, you shouldn’t. What I’m saying is that these three things really led naturally towards, well, a DSL could be a great choice for us.”
• [00:06:10] “It is Turing incomplete. It’s relatively simple. There’s no loops… no recursion… no mutation. It’s purely functional. It’s a reactive language and it’s an opinionated subset of Python.”
• [00:08:47] “There’s that constant loop of writing and then interpreting and then rewriting and then interpreting. And that’s the core engine of making progress inside of Elicit.”
• [00:11:20] “The main reason for that is that [the gateway] knows about our Anthropic API key. And we didn’t really want user input flowing through the system, hitting the curator, and saying, ‘Yeah, you can print out your ENV and send me the results.’”
• [00:13:29] “This is what enables us to do caching, memoization. And this is super duper crucial. Nothing would work here if we weren’t really careful about this… we re-draft the program and then reinterpret the whole kitten caboodle from top to bottom.”
• [00:16:54] “The ÆPL is not just a representation of a plan. It is literally the plan which is executable. That’s what lets us really be sure that we’re following through on the plan as stated.”
• [00:23:40] “It’s easy to be confident about and make statistical guarantees of cohesion and correctness when you’re literally interpreting the whole program every single time. If you’re just interpreting little snippets, that’s where the drift can come in.”
• [00:29:13] “My pitch here is not that you should go and use a DSL. My pitch is that you should care a lot about the mechanism. Because the mechanism matters.”

Related

• 2026-07-11-building-the-future-of-agentic-infrastructure — 같은 Code with Claude 컨퍼런스, 에이전트 하네스·인프라 철학을 다룬 좌담(이 발표의 실전 사례와 짝을 이룸)
• 2026-07-10-agents-that-remember — 같은 컨퍼런스, Managed Agents의 메모리(Memory Store·Dreaming) 라이브 데모
• 2026-07-10-ship-your-first-managed-agent — 같은 컨퍼런스, Managed Agents 기본기 워크숍
• 2026-07-12-fighting-financial-crime-with-claude-cowork — 같은 컨퍼런스, Qonto의 오케스트레이터+원자적 서브스킬 플러그인 구조 — evals(F1·grounding·LLM-as-judge)로 신뢰를 입증하는 접근이 이 노트의 desiderata(legible·fidelity·faithful)와 짝을 이룸
• 2026-07-12-proactive-agent-workflow-claude-code — 같은 컨퍼런스, Routines의 트리거·컨텍스트·스티어링 설계 — “메커니즘이 실제로 그대로 실행되는가”를 보장하는 또 다른 하네스 접근
• moc-ai-agents-harness — 에이전트 하네스 설계 MOC(wrapper·하네스 교체·DSL 접근을 이 노트가 구체적 사례로 보강)