Previously I’ve made the case for running an AI-driven incident-response pipeline entirely inside a Postgres cluster: pgvector for retrieval, EDB Postgres AI Hybrid Manager’s on-board model serving for inference, AI Studio powered by Langflow for orchestration, and a regular Postgres table for the audit trail. One component in that stack was not Postgres: the Langflow runtime. This post examines what happens when that last piece moves into the database too.

작성자: Chris Chiappone 작성일: 2026년 3월 31일 우리는 ‘에이전트 시대’에 살고 있습니다. 매주 새로운 프레임워크가 등장하며, 인프라를 자율적인 지능 계층으로 감싸겠다고 약속합니다. 그 제안은 꽤 매력적입니다. 스크립트 작성을 멈추고 목표만 설정하면, ‘어떻게’ 할지는 AI가 알아서 처리하도록 맡기자는 것입니다. 하지만 Hybrid Manager로 관리되는 EDB Postgres AI 환경의 자동화를 설계하면서 저는 장벽에 부딪혔습니다. 부하에 따라 클러스터를 자율적으로 확장하는 에이전틱 DB(Agentic DB) 아키텍처를 구상하던 중, 무언가 잘못되었다는 것을 깨달았습니다. 실제 요구사항을 들여다볼수록 ‘에이전트’ 패턴은 문제에 대한 억지 해결책처럼 느껴졌습니다. 핵심 데이터베이스...

When designing an AI-driven incident-response pipeline for a database operations team, it is beneficial to run the model, the vector store, the orchestration, and the audit log inside the same Postgres cluster. The specific stack used in EDB Agent Factory consists of: pgvector for retrieval, EDB Hybrid Manager on-board model serving for inference, AI Studio powered by Langflow for orchestration, and a regular Postgres table for the audit trail.

AI agents are showing up everywhere, but not every problem in a Postgres environment should be handed to a probabilistic system. This post walks through why core control-plane tasks like scaling and failover still belong in deterministic, policy-driven automation, while agents deliver more value in analysis, triage, and recommendation.