Inferable

워크플로는 자체 머신에서 실행된다. 방화벽 뒤나 프라이빗 VPC 안이어도, 관리할 배포 단계가 없다. 워커가 롱 폴링으로 컨트롤 플레인에 닿으므로 인바운드 포트를 열거나 로드 밸런서를 설정할 필요가 없다. 작업을 자체 네트워크 밖으로 못 내보내는 팀에게, 이 설계가 호스팅 대안과의 갈림길이다.

입력 스키마나 로직이 바뀌면, 옛것을 고치는 대신 새 버전으로 정의한다. Inferable은 이미 실행 중인 작업의 버전을 그대로 묶어 두므로, 변경을 단계적으로 내보내고 진행 중인 일은 처음 코드로 끝난다. 작은 수정이 고객이 기다리는 것을 망가뜨리지 않을까 하는 늘 있는 걱정이 사라진다.

워크플로는 스스로 멈추고, Slack이나 이메일로 다음 단계의 승인 또는 거부를 사람에게 청한다. 맥락은 그대로 따라온다. 실행은 답이 올 때까지, 1분이든 1주일이든 기다렸다가 멈춘 곳에서 이어간다. 데이터 삭제나 결제처럼 위험을 안은 단계를, 대기 로직을 직접 짜지 않고 사람 손으로 붙잡을 수 있다.

런타임은 구조화된 모델 응답을 매번 스키마에 맞춰 해석하고, 어긋나면 그 실행을 재시도한다. 자유 텍스트를 해석하며 잘 버티기를 바라는 대신, 다음 단계로 그대로 넘길 수 있는 타입이 있는 항목을 얻는다. 티켓 분류, 메뉴 스크래핑, 양식 추출은 이게 안정적으로 돌아가는 데 기대고 있다.

비싸거나 부작용이 있는 단계는 메모해 분산 저장소에 캐시할 수 있어, 재시작이나 재시도에도 다시 돌지 않는다. 아홉 번째에서 실패한 여러 단계 작업은 아홉 번째에서 이어지고, 첫 여덟 단계는 그대로다. 오래 도는 AI 처리가 프로덕션에서 감당할 만한 것이 된다.

단일 워크플로를 넘어, Inferable은 도구를 써서 목표에 도달하는 AI 에이전트도 다룬다. 모든 실행은 타임라인 화면에 나타나 각 단계를 추적한다. 같은 이벤트를 자체 관측성 도구로 흘려보낼 수도 있다. 에이전트가 길을 벗어났을 때, 어떤 호출이 원인인지는 타임라인에서 알 수 있다.

컨트롤 플레인, 플레이그라운드, CLI, SDK가 모두 MIT 라이선스로 공개돼 있다. 스택 전체를 자체 인프라에 올리면 데이터와 모델을 완전히 쥐고, 벤더에 묶이지 않는다. 보안 심사에서 관리형 서비스가 탈락하는 팀에게 자체 호스팅이 그 길이다.