tambo

생성형 컴포넌트는 메시지에 대한 응답으로 한 번 렌더링한 뒤 그대로 남는다. 이름, 설명, props 스키마와 함께 컴포넌트를 등록하면 에이전트가 언제 보여줄지 정한다. 차트, 데이터 시각화, 요약 카드가 이 패턴에 맞는다. props는 에이전트가 쓰므로 기존 스타일과 로직이 그대로 살아남는다. 사용자가 지난 분기 숫자의 내역을 요청하면, 해석해야 할 텍스트 벽 대신 자기 브랜드 색으로 된 진짜 차트를 받는다.

상호작용 컴포넌트는 페이지에 남아 대화를 넘나들며 ID로 갱신된다. 장바구니, 할 일 보드, 스프레드시트는 사용자가 계속 채팅하는 동안 상태를 유지한다. AI는 답을 토해내기를 멈추고 자기 인터페이스의 살아 있는 일부를 편집하기 시작한다. 이 패턴이 Tambo를 순수 텍스트 챗봇과 갈라놓는다. 큰 차이다.

Tambo는 자체 에이전트를 함께 제공하므로 외부 프레임워크를 덧붙일 필요가 없다. 응답이 도착하는 대로 점진적 props 갱신, 메시지 스레드 기록, 오류 처리를 맡는다. 사용자는 데이터가 흐르면서 컴포넌트가 채워지는 것을 본다. 이는 완전한 응답을 기다리는 것보다 빠르게 읽힌다. AI 경험의 지루한 부분을 공짜로 얻는다. 그게 핵심이다. 취소 로직을 다섯 번째로 다시 만들고 싶은 사람은 없다.

SDK는 Model Context Protocol을 통해 데이터베이스, API, 외부 시스템에 연결한다. 이로써 에이전트는 지어내는 대신 실제 데이터에 닿는다. 클라이언트 쪽에서도 서버 쪽에서도 작동한다. 이미 MCP 서버를 돌리는 팀에게는 에이전트에 손을 달아주는 가장 깔끔한 방법이다. 기존 데이터베이스를 채팅 기반 인터페이스에 연결하려면 예전에는 소스마다 맞춤 연동이 필요했다. 이것은 그 일을 단일 연결 지점으로 접어 넣는다.

백엔드를 어떻게 돌릴지는 직접 고른다. 완전한 제어를 위해 셀프 호스팅하거나, 관리형 키로 더 빠르게 시작하려면 Tambo Cloud를 쓴다. 스타터 CLI가 API 키를 env 파일에 곧바로 써 넣으므로 첫 요청이 거의 의식 없이 작동한다. 설정을 찾아 헤맬 필요가 없다. 데이터 규칙이 엄격한 팀은 모든 것을 자기 벽 안에 둘 수 있고, 그냥 출시하고 싶은 팀은 호스팅 옵션에 기대어 서버 설정 파일을 한 번도 건드리지 않을 수 있다.

등록은 선언적이다. 컴포넌트를 설명하고 Zod로 만든 props 스키마를 넘기면, 에이전트가 그 계약을 써서 유효한 props를 스트리밍한다. 이 패턴은 Zod에 기대므로 많은 React 팀이 이미 쓰는 작업 흐름에 그대로 들어간다. 수동 라우팅 없이 컴포넌트가 알맞은 자리에 나타난다는 뜻이기도 하다. 접착 코드가 없다. switch 문도 없다.