같은 코어, 다른 입구
GEODE를 부르는 길은 여럿입니다. 터미널에서 명령으로, Slack 메시지로, 예약된 시각에 스스로. 세 길은 입구만 다릅니다. 안으로 들어오면 모두 같은 코어를 지납니다. 그 코어가 안쪽 agentic 루프입니다.
모듈 목록을 나열하는 대신, 요청 하나가 흐르는 길을 끝까지 따라가며 구조를 익히겠습니다. 같은 일을 세 입구로 들어가서 세 번 봅니다.
1. CLI 작업
geode "..."를 실행하면 thin CLI가 먼저 뜹니다. CLI 자체는 모델을 호출하지 않습니다. 대신 Unix 도메인 소켓으로 serve 데몬에 작업을 넘깁니다. 데몬이 떠 있지 않으면 백그라운드에서 띄운 뒤 연결합니다(core/cli/ipc_client.py). 데몬은 작업을 AgenticLoop에 넘기고, 루프가 도구를 돌려 답을 만든 뒤, 같은 소켓으로 결과를 돌려보냅니다.
geode "..." -> thin CLI
| (Unix socket, line-delimited JSON)
v
serve daemon -> AgenticLoop -> tools
^ |
+-------- answer ---------------+데몬을 한 번 띄워 두면 MCP 서버, 스킬, 메모리, 훅을 매번 새로 켤 필요가 없습니다. CLI는 얇게 유지되고, 무거운 상태는 데몬에 머뭅니다.
2. 게이트웨이 메시지
Slack이나 Discord 채널에 올라온 메시지는 다른 입구로 들어옵니다. poller(core/server/supervised/)가 채널을 지켜보다가 새 메시지를 받습니다. binding(core/integrations/messaging/binding.py)이 그 메시지를 어떤 세션으로 보낼지 라우팅하고, lane queue가 같은 세션의 요청을 직렬화해 동시성을 제어합니다. 그 안에서 AgenticLoop가 같은 방식으로 돕니다. 답이 나오면 채널로 회신하고, 필요하면 알림을 보냅니다.
Slack / Discord message
|
v
poller -> binding (route) -> session lane -> AgenticLoop -> tools
|
reply to channel + notification입구는 CLI와 다르지만, binding.py가 메시지를 넘기는 곳은 같은 AgenticLoop입니다. serve 데몬과 게이트웨이 운영은 Serve와 게이트웨이에서 다룹니다.
3. 예약된 자기개선 실행
세 번째 입구는 사람이 아니라 스케줄러입니다. 예약된 시각이 되면 스케줄러(core/scheduler/service.py)가 실행을 트리거합니다. 이번에는 사용자 작업이 아니라 바깥쪽 루프가 돕니다. autoresearch/train.py가 호출당 감사 한 번을 돌립니다. 정책 파일 하나를 변형하고, Petri 감사로 측정하고, 점수 변화를 귀속한 뒤, 기준을 넘으면 baseline을 갱신하고 아니면 정책을 되돌립니다.
scheduled time
|
v
scheduler -> autoresearch/train.py
|
mutate policy -> Petri audit -> attribute -> promote / revert여기서 측정 대상이 되는 트랜스크립트는 결국 같은 AgenticLoop가 만든 것입니다. 바깥쪽 루프 전체는 폐루프에서 다룹니다.
세 흐름이 만나는 곳
세 입구는 서로 다른 코드로 시작합니다. CLI는 IPC 클라이언트로, 게이트웨이는 poller와 binding으로, 자기개선 실행은 스케줄러로 시작합니다. 그러나 셋 다 같은 AgenticLoop와 같은 메모리, 훅, LLM 라우터, 서브에이전트 오케스트레이션을 지납니다. 입구를 바꿔도 코어는 하나입니다. 계층이 어떻게 나뉘는지는 4-계층 스택에서 이어집니다.