Agentic Decision Engine: 바이엘이 육종 분석 플랫폼 앞에 22개 전문 에이전트를 세운 방법

기존 업무 시스템 앞에 에이전트를 세우는 일의 대부분은 프롬프트 밖에 있습니다. 바이엘 크롭사이언스는 육종 분석 플랫폼 앞에 감독 에이전트와 전문 에이전트 22개를 세워 1단계 질문의 약 80%를 엔지니어 없이 풀었습니다. 따라 하려면 상태 저장, 신원 경계, 에이전트별 도구 범위, 작업 성공 기준의 관측을 처음부터 설계해야 합니다.

요약

바이엘 크롭사이언스는 작물·지역·팀별 식물 육종 데이터로 수백 개의 ML 모델 설정을 돌립니다. 이 실행을 맡는 내부 플랫폼 CDE(Connected Decision Engine)가 관리하는 모델 설정은 500개를 넘습니다. 사용자가 늘자 병목은 실행이 아니라 결과를 이해하는 쪽으로 옮겨 갔습니다. 육종가와 분석가는 결과 하나를 해석하려고 API, 문서, 메타데이터 저장소, 대시보드, 로그를 직접 오가야 했습니다. 바이엘과 AWS는 CDE를 고치지 않고 그 위에 자연어로 묻고 답하는 멀티 에이전트 층 ADE(Agentic Decision Engine)를 올렸습니다. LangGraph로 짠 Supervisor Agent(감독 에이전트)가 질문을 분류해 전문 에이전트 22개 가운데 하나로 보냅니다. 에이전트들은 Amazon Bedrock AgentCore(AWS의 에이전트 실행·운영 기반) 위에서 돌고, AgentCore Gateway를 거쳐 API 도구 약 20개를 씁니다. 글은 바이엘과 AWS가 함께 쓴 벤더 공동 저술입니다.

ADE는 전사 공개가 아니라 제한된 사용자군에 먼저 열렸고, 지금까지 100명 넘게 썼습니다. 1단계에서 사용자 질문의 약 80%를 엔지니어 없이 해결했고, 워크플로 실패 진단은 1시간 이상에서 10분 미만으로 줄었습니다. API마다 MCP 서버를 따로 세우지 않고 Gateway로 노출해 API별 통합 부담을 99% 넘게 줄였고(벤더 발표, 기준선 미공개), 프롬프트 캐싱으로 입력 토큰 비용을 20~30% 낮췄습니다. 무엇을 해결로 셌는지는 원문에서 밝히지 않았습니다. 저자들은 그 이유를 모델 성능이 아니라 다섯 가지 설계 결정(상태 외부화, 신원 경계 분리, 모델의 인터페이스 계약, 도구 범위 통제, 도구의 에이전트 승격)과 차단 이슈 35건을 끝까지 추적한 출시 준비에서 찾습니다. 아래에서는 이 설계를 개념별로 풀고, 우리 업무 시스템 앞에 에이전트 층을 세울 때 정할 것을 덧붙였습니다.

핵심 메커니즘

Supervisor Agent와 Specialist Agents: 질문을 분류해 좁은 전문가에게 보내는 구조

Supervisor Agent는 모든 질문이 들어오는 단일 진입점입니다. 먼저 ElastiCache에 같은 질문의 답이 남아 있는지(TTL 안의 응답 캐시) 확인하고, 없으면 질문을 분류해 맞는 전문 에이전트로 보냅니다. 질문이 여러 영역에 걸치면 여러 에이전트의 결과를 합쳐 답합니다. 전문 에이전트는 영역 하나만 맡고 그 영역의 도구와 데이터만 가집니다. 원문이 든 예는 넷입니다. Domain Expert Agent는 개념 질문에 RAG(문서 검색 기반 답변)로 답합니다. S3의 도메인 문서를 Amazon Titan Text Embeddings V2로 임베딩해 OpenSearch Serverless에 색인해 둔 것입니다. Operational Agent는 CDE에서 워크플로의 실시간 상태와 결과를 가져오고, Troubleshooting Agent는 운영 텔레메트리를 분석하며, Visualization Agent는 차트를 그리거나 기존 대시보드를 돌려줍니다.

여기에 Models as Skill(모델을 skill로 등록하는 방식)이 더해집니다. 모델 코드와 문서를 skill 정의로 바꿔 중앙 레지스트리에 넣으면, 에이전트가 특정 모델에 관한 질문에 일반 지식이 아니라 그 모델의 실제 구현을 근거로 답합니다. 에이전트 하나가 도구 20개를 모두 들면 선택지가 넓고 프롬프트도 길어지므로, 영역과 도구가 많을수록 이 구조가 이득입니다. 가상 예시로, 품질 부서의 『지난주 불량 예측 모델 결과가 왜 바뀌었나』라는 질문은 실행 기록을 보는 Operational과 모델 문서를 보는 Domain Expert가 나눠 답하고 Supervisor가 합칩니다.

Externalized State: 런타임 세션 밖에 두는 작업 상태

AgentCore runtime은 세션마다 격리된 실행 공간을 주고 프레임워크를 가리지 않고 에이전트를 올립니다. 하지만 세션은 영속 저장소가 아닙니다. 인스턴스가 늘거나 재시작되거나 세션 경계를 넘으면 메모리에 있던 대화와 작업 진행 상태가 사라집니다. 팀은 LangGraph를 고른 이유로 명시적인 그래프 제어 흐름과 checkpointing(단계마다 상태 저장)을 듭니다. 그래프의 각 단계가 끝날 때마다 상태를 DynamoDB에 checkpoint로 쓰고, 새 인스턴스가 그 checkpoint를 읽어 이어서 실행합니다. 세션 기록, 사용자 피드백, 분석 데이터는 Aurora PostgreSQL에 따로 둡니다.

AgentCore Gateway와 Tool Surface: API를 에이전트별로 잘라 주는 도구 창구

Gateway는 백엔드 API를 MCP(Model Context Protocol, 에이전트가 도구를 부르는 표준) 도구로 노출하고, 인증과 인가를 에이전트 코드 밖에서 처리합니다. 팀은 API마다 MCP 서버를 하나씩 세우지 않고 OpenAPI 명세를 Gateway에 등록했습니다. 그다음 에이전트마다 쓸 수 있는 도구를 정해 줬습니다. 도구 정의 하나하나가 프롬프트 토큰을 차지하므로, 범위를 좁히면 토큰이 줄고 에이전트가 고를 선택지도 줄어듭니다. 카탈로그가 커지면 Gateway의 의미 기반 도구 검색으로 필요한 도구를 찾게 할 수 있습니다. 원문 기준 노출된 도구는 약 20개이고, 이 방식으로 API별 통합 부담이 99% 넘게 줄었다고 밝힙니다.

Layered Identity: 사용자·서비스·하위 시스템의 신원을 홉마다 나누기

요청은 여러 홉을 거칩니다. React 화면 앞의 identity proxy가 Microsoft Entra ID로 사용자를 확인하고, 에이전트와 AWS 서비스 사이 호출은 IAM이 맡으며, Gateway에서 CDE로 가는 호출은 Gateway의 outbound 인가가 맡습니다. 그 사이에 Lambda request interceptor(요청 검사 함수)가 사용자 정의 검증을 하고, 하위 도구가 필요로 하는 인가 속성을 넘겨줍니다. 저자들의 원칙은 홉마다 issuer(발급자), audience(대상), claims, scopes, 자격 증명 수명을 따로 정하는 것입니다. 권한은 에이전트마다 최소로 줍니다. Troubleshooting Agent는 읽기 전용이고, Domain Expert Agent는 관련 없는 CDE API를 부를 수 없습니다.

Tool-to-Agent Promotion: 상태와 재시도를 가진 기능은 에이전트로 올리기

시각화는 처음에 도구였습니다. 쓰다 보니 실패하면 다시 시도하고, 데이터에 맞는 차트 종류를 고르고, 오류를 처리하고, 새로 그릴지 기존 대시보드를 돌려줄지 판단하는 일까지 떠안게 됐습니다. 팀은 이 기능을 Visualization Agent로 올렸습니다. 에이전트는 AgentCore Code Interpreter(격리된 코드 실행 환경)에서 matplotlib과 Plotly로 차트를 그리고, 데이터는 S3로 주고받으며, Amazon Quick이나 Power BI 자산을 돌려줄 수도 있습니다. 판단 기준은 그 기능이 상태, 재시도, 계획, 표현 가운데 하나라도 스스로 가지는지입니다. 입력을 받아 값 하나를 돌려주는 기능은 도구로 두는 편이 단순합니다.

Task-Success Observability와 Cost Attribution: 호출 성공과 일의 성공을 따로 재기

출시 준비 중 팀은 예외 처리기가 에이전트의 실패를 성공으로 가리고 있다는 것을 발견했습니다. 호출은 정상으로 끝났는데 답은 비어 있는 경우가 대시보드에 드러나지 않았던 것입니다. 그래서 실패 경로마다 CloudWatch 지표를 심고, 도구 오류·스로틀링·모델 타임아웃·구조화 출력 검증 실패에 알람을 걸었습니다. 추적과 로그는 에이전트 경계를 넘어 요청 하나를 끝까지 따라갑니다.

비용은 세 장치를 함께 씁니다. Bedrock application inference profile(애플리케이션 단위 사용량 귀속)이 청구 금액을 워크로드에 묶고, 요청 메타데이터와 모델 호출 로그가 토큰을 특정 에이전트·기능·요청에 묶고, IAM principal이 누가 호출했는지를 더합니다. 그러자 상호작용당 비용과 비싼 에이전트가 보였습니다. MCP 도구를 여러 번 부르는 Visualization과 Operational이 토큰을 가장 많이 썼습니다. 또 매 요청 반복되는 큰 입력 앞부분에 캐시 활동이 전혀 없다는 것도 드러났습니다. 고정된 지시문과 도구 정의를 캐시하자 입력 토큰 비용이 20~30% 줄고 지연도 짧아졌습니다.

통념과 다른 주장

저자가 든 사례

표현형 워크플로 실패 진단

• 상황: 육종가가 표현형(phenotyping, 작물의 겉으로 드러난 형질 측정) 분석 워크플로가 왜 실패했는지 물었습니다. 이전에는 원인 파악에 1시간 이상 걸렸습니다.
• 한 일: Supervisor가 질문을 Troubleshooting Agent로 보냈고, 이 에이전트가 Gateway를 거쳐 CloudWatch 텔레메트리와 CDE 실행 상태를 함께 읽었습니다.
• 결과: 진단 시간이 10분 미만으로 줄었습니다. 표본 수와 측정 방법은 원문에서 밝히지 않았습니다.
• 연결: Supervisor·Specialist 구조와 Layered Identity(읽기 전용 권한)의 사례입니다.

출시 준비와 차단 이슈 35건

• 상황: 제한 공개를 앞두고 Critical Workload Review와 Well-Architected 리뷰(Generative AI Lens)를 받았습니다.
• 한 일: 리뷰가 찾은 실패 가시성 부족에는 알람을 강화했고, 바뀔 수 있는 이미지 태그에는 불변 버전 이미지를, 스캔 누락에는 ECR 푸시 시 스캔과 수명 주기 정책을 붙였습니다. 애플리케이션과 서비스 한도를 부하 시험으로 확인했습니다.
• 결과: 부하 시험이 찾은 빈 응답 네트워킹 결함을 출시 전에 고쳤고, 차단 이슈 35건을 모두 해결한 뒤 공개했습니다.
• 연결: Task-Success Observability와 두 번째 통념과 다른 주장의 사례입니다.

토큰 비용 추적과 프롬프트 캐싱

• 상황: 에이전트가 늘자 어디서 비용이 나는지 보이지 않았습니다.
• 한 일: inference profile, 요청 메타데이터 로그, IAM principal을 묶어 에이전트별 토큰을 봤고, 캐시가 걸리지 않던 고정 앞부분(지시문·도구 정의)을 캐시했습니다.
• 결과: Visualization과 Operational이 토큰을 가장 많이 쓴다는 것이 드러났고, 입력 토큰 비용이 20~30% 줄었습니다. 에이전트별 금액은 원문에서 밝히지 않았습니다.
• 연결: Cost Attribution과 AgentCore Gateway(도구 정의도 토큰)의 사례입니다.

AWS Unified Operations와의 협업 방식

• 상황: 사내 팀만으로 설계부터 운영까지 처음 해 보는 에이전트 플랫폼을 올려야 했습니다.
• 한 일: 바이엘의 운영 방식을 아는 지정 TAM과 생성형 AI DSE가 팀의 일원으로 주 3회 기술 스탠드업에 참여해 설계 결정을 함께 했습니다.
• 결과: 출시 뒤에도 DSE가 정기적으로 만나고, ADE의 핵심 CloudWatch 알람은 AWS Incident Detection and Response에 등록돼 알람 5분 안에 AWS 장애 대응 엔지니어가 붙습니다. 보안 사고는 AWS Security Incident Response가 지원합니다.
• 연결: 출시 준비 전반의 사례입니다. 벤더 협업 모델 자체가 글의 주제 가운데 하나입니다.

기술 디테일: 우리 시스템 앞에 에이전트 층을 세우려면

아래는 원문 구조를 우리 업무 시스템(MES, PLM, 품질·실험 데이터 플랫폼 등)에 옮길 때 필요한 설계로, AX Review가 새로 작성했습니다. 필드 이름과 숫자는 가상 예시입니다.

Supervisor의 라우팅을 안정적으로 돌리려면 라우팅 호출을 답변 호출과 분리하고 temperature 0, 구조화 출력으로 강제합니다. 출력에는 route(전문 에이전트 ID), secondary(함께 볼 에이전트 목록), confidence(0~1), needs_merge, reason(한 줄)을 둡니다. 스키마 검증에 실패하면 한 번만 다시 묻고, 그래도 실패하면 schema_fail 결과 코드를 남깁니다. confidence가 0.7 아래면 사용자에게 영역을 되묻습니다. 라우팅 정확도는 실제 질문 200건에 현업이 정답 영역을 달아 둔 평가 세트로 재고, 같은 세트를 3회 돌려 결과가 바뀌는 질문 비율을 5% 아래로 맞춥니다. 모델을 바꿀 때는 이 세트와 도구 호출이 3단계 이상 이어지는 질문 50건을 함께 돌려, 구조화 출력 통과율 100%와 도구 호출 성공률이 기존보다 떨어지지 않는지 확인합니다. 원문이 추론 모드 버전을 채택하지 않은 판단을 우리 쪽 숫자로 내리는 장치입니다.

{
  "route": "troubleshooting",
  "secondary": ["operational"],
  "confidence": 0.86,
  "needs_merge": true,
  "reason": "실행 실패 원인과 현재 상태를 함께 묻는 질문"
}

도구 범위와 권한을 에이전트별로 정하려면 에이전트마다 허용 도구 목록과 읽기·쓰기 여부를 설정 파일 하나로 관리합니다. 예를 들어 troubleshooting: tools=[get_run_status, get_logs, get_metrics], mode=read_only처럼 적고, 같은 목록에서 Gateway의 도구 범위와 IAM 정책을 함께 생성해 둘이 어긋나지 않게 합니다. 에이전트 하나에 도구는 8개 이하로 시작합니다. 넘으면 영역을 쪼개거나 의미 기반 도구 검색을 켭니다. 쓰기 도구(재실행, 설정 변경)는 첫 단계에서 열지 않고, 열 때는 사용자 확인 단계를 그래프에 넣습니다.

상태를 런타임 밖에 두려면 checkpoint 키를 thread_id = 사용자 ID + 대화 ID로 정하고, 그래프 노드가 끝날 때마다 DynamoDB에 씁니다. 항목에 TTL(예: 30일)을 붙여 오래된 대화를 지웁니다. 검증은 간단합니다. 3단계짜리 질문을 돌리다 2단계에서 컨테이너를 강제로 내리고, 새 인스턴스가 같은 thread_id로 3단계부터 이어 가는지 봅니다.

프롬프트 캐싱이 실제로 걸리게 하려면 프롬프트를 바뀌지 않는 부분(시스템 지시문, 도구 정의)과 바뀌는 부분(대화 기록, 이번 질문)으로 나누고, 고정 부분을 앞에 둔 뒤 그 끝에 캐시 지점(Bedrock Converse API의 cachePoint)을 둡니다. 도구 정의 순서가 요청마다 바뀌거나 지시문에 현재 시각이 들어가면 캐시가 깨집니다. 모델 호출 로그의 캐시 읽기 토큰을 에이전트별로 집계해, 0이면 앞부분이 매번 달라지고 있다는 신호로 봅니다.

작업 성공을 지표로 남기려면 요청마다 request_id, agent, tool, outcome, tokens_in, tokens_out, cache_read_tokens, latency_ms, user_group 한 줄을 남깁니다. outcome은 아래 여섯 값 중 하나입니다. 전송이 성공해도 답이 비었으면 empty_answer로 기록하는 것이 핵심입니다. 같은 필드를 비용 귀속에도 쓰면 상호작용당 비용과 에이전트별 비용이 한 표에서 나옵니다.

실패하는 경우와 대응. 라우팅이 엉뚱한 에이전트로 가면 그 에이전트는 도구가 없어 그럴듯한 일반론으로 답합니다. 전문 에이전트마다 “내 범위 밖” 응답을 정해 두고 Supervisor가 다시 분류하게 합니다. 여러 에이전트의 결과를 합칠 때 숫자가 서로 다르면 합치지 말고 출처별로 나란히 보여 줍니다. 응답 캐시는 실행 상태처럼 자주 바뀌는 답에 쓰면 낡은 답을 돌려주므로, 개념 질문에만 걸고 상태 질문은 TTL을 분 단위로 짧게 둡니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	8주 동안 하는 일
스폰서	R&D 또는 데이터 플랫폼 총괄 임원	대상 플랫폼과 제한 사용자군 승인
플랫폼 오너	기존 분석 플랫폼 책임자 1명	문의 이력 제공, 에이전트 영역 지도 승인
현업 전문가	연구원·분석가 3명	질문 200건 정답 영역 라벨링, 답 정확도 판정
에이전트 엔지니어	2명	Supervisor·전문 에이전트 3개, 상태 저장, 라우팅 평가
플랫폼·SRE	1명	컨테이너 파이프라인, 지표·알람, 부하 시험
보안	1명	홉별 신원 설계, 에이전트별 권한 검토
FinOps	1명	비용 귀속 태그, 상호작용당 비용 보고
벤더	클라우드 TAM·전문가	주 2~3회 기술 스탠드업, 출시 리뷰

시작 전 준비물: 최근 3개월 동안 엔지니어에게 들어온 문의 300건(메신저·티켓), 대상 플랫폼의 OpenAPI 명세, 현재 권한 표(누가 어떤 API를 부르나), 로그·지표·대시보드 목록, 모델이나 워크플로의 문서와 코드 위치, 사내 SSO 연동 방식.

주차	할 일	산출물
1주	문의 300건을 영역별로 분류하고 상위 3개 영역 선정	질문 분류표, 에이전트 영역 지도
2주	영역별 도구 목록과 읽기·쓰기 구분, 평가 세트 200건 라벨링	도구 범위 설정 파일, 평가 세트
3~4주	Supervisor와 전문 에이전트 3개 구축, checkpoint 저장	동작하는 프로토타입, 라우팅 정확도
5주	홉별 신원 설계와 권한 검토	신원 흐름도, 권한 승인서
6주	결과 코드 지표, 알람, 비용 귀속, 캐시 지점	관측 대시보드, 상호작용당 비용
7주	출시 리뷰, 부하 시험, 차단 이슈 목록 정리	차단 이슈 목록과 해결 기록
8주	제한 사용자 20명에게 공개	2주 운영 보고서

1주차 상세: 첫날 플랫폼 오너가 문의 이력을 내보냅니다. 둘째 날부터 셋째 날까지 엔지니어와 현업 전문가가 문의마다 영역(개념 설명, 실행 상태, 실패 원인, 시각화, 모델 세부)과 필요한 데이터 출처를 붙입니다. 넷째 날 건수 상위 3개 영역을 고르고, 다섯째 날 스폰서와 30분 회의로 영역 지도를 확정합니다. 원문 사례처럼 실패 원인 질문이 많다면 읽기 전용 Troubleshooting 에이전트가 첫 후보입니다.

현업·플랫폼 담당자 질문: 지금 엔지니어에게 가장 자주 들어오는 질문 다섯 가지는 무엇입니까? 그 질문에 답하려고 몇 개 시스템을 열어 봅니까? 답이 틀렸을 때 손해가 가장 큰 질문은 무엇입니까? 에이전트가 절대 하면 안 되는 일(재실행, 설정 변경, 외부 공유)은 무엇입니까? 사용자 그룹마다 볼 수 없는 데이터가 있습니까?

진행 판정 기준(예시): 제한 공개 2주 뒤 엔지니어 없이 끝난 질문이 60% 이상, 현업이 판정한 표본 100건의 정확도가 90% 이상, empty_answer가 0건이고 차단 이슈가 모두 해결됐으면 사용자군과 에이전트 수를 늘립니다. 하나라도 미달이면 2주 보완 후 다시 판정합니다.

AX 적용 제언. 이 구조가 맞는 곳은 이미 잘 돌아가는 분석·운영 플랫폼이 있는데, 결과를 해석하는 질문이 소수 엔지니어에게 몰리는 조직입니다. 제조의 MES·품질 분석, 제약·화학의 실험 데이터 플랫폼, 금융의 리스크 모델 운영이 대표적입니다. 순서는 문의 이력으로 영역 지도 그리기 → 읽기 전용 전문 에이전트 3개 → 신원·권한 → 작업 성공 관측과 비용 귀속 → 제한 공개가 무난합니다. 기존 플랫폼을 고치지 않고 그 앞에 층을 세우므로 현업 스폰서를 설득하기 쉽습니다. 다만 일정의 절반 이상을 프롬프트가 아닌 운영 준비에 배정해야 합니다. 원문 팀도 출시 전 차단 이슈 35건을 풀었습니다. 벤더를 쓴다면 문제 접수 창구가 아니라 주 2~3회 설계 회의에 들어오는 작업 인력으로 계약하는 편이 원문의 방식에 가깝습니다.

원문 사례

항목	내용
발표처	AWS Machine Learning Blog(2026.10.23), 바이엘 Subbu Dandamudi · Leo de Melo, AWS Mahnoor Hussain · Ram Pamidimukkala(TAM) · Sai Pavan Kasani(DSE)
기존 플랫폼	CDE(Connected Decision Engine), 모델 설정 500개 이상, 육종 ML 워크플로 배포 · 조율 · 감시 · 재사용
새 층	ADE(Agentic Decision Engine), Supervisor Agent와 전문 에이전트 22개, API 도구 약 20개
실행 기반	Amazon Bedrock AgentCore(runtime, Gateway, Code Interpreter), LangGraph
데이터	DynamoDB(checkpoint), Aurora PostgreSQL(세션 · 피드백 · 분석), ElastiCache(응답 캐시), S3 + Titan Text Embeddings V2 + OpenSearch Serverless(RAG), CloudWatch
신원	Microsoft Entra ID, IAM, Gateway outbound 인가, Lambda request interceptor
배포	React 화면, GitHub Actions → Amazon ECR → AgentCore runtime
결과	제한 사용자군 100명 이상, 1단계 질문 약 80% 엔지니어 없이 해결, 실패 진단 1시간 이상 → 10분 미만
비용 · 통합	프롬프트 캐싱으로 입력 토큰 비용 20~30% 절감, API별 통합 부담 99% 이상 감소(벤더 발표)
출시 준비	차단 이슈 35건, CWR · Well-Architected(Generative AI Lens) 리뷰, 부하 시험
운영 협업	TAM · DSE와 주 3회 스탠드업, Incident Detection and Response(알람 5분 안 대응)
다음 단계	하이브리드 클라우드 에이전트 상호 운용, Amazon Bedrock Guardrails 검토

핵심 개념

CDE / ADE

바이엘의 기존 ML 의사결정 엔진(Connected Decision Engine)과 그 앞에 세운 에이전트 층(Agentic Decision Engine).

Models as Skill

모델 코드와 문서를 skill 정의로 바꿔 중앙 레지스트리에 두고, 에이전트가 그 모델의 실제 구현을 근거로 답하게 하는 방식.

AgentCore Code Interpreter

에이전트가 생성한 코드를 격리된 환경에서 실행하는 기능. 원문에서는 차트 생성에 쓴다.

application inference profile

Bedrock 사용량과 청구 금액을 애플리케이션·워크로드 단위로 묶는 설정.

prompt caching

요청마다 같은 프롬프트 앞부분을 캐시해 다시 읽을 때 비용과 지연을 줄이는 기능.

Critical Workload Review

중요 워크로드의 출시 전 위험을 점검하는 AWS 리뷰. 원문에서는 Well-Architected 리뷰와 함께 받았다.

AWS Unified Operations

지정 TAM과 전문 엔지니어가 고객 팀과 함께 설계·운영을 맡는 AWS 지원 방식.

내 메모

TODO: 내 생각 추가

원문: Subbu Dandamudi, Leo de Melo, Mahnoor Hussain, Ram Pamidimukkala, Sai Pavan Kasani, “How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations”(AWS Machine Learning Blog, 2026.10.23). 바이엘과 AWS가 함께 쓴 글이며 결과 수치는 저자 발표입니다. 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 글의 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, JSON 예시, 결과 코드와 알람 기준, 8주 일정, 판정 기준, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. 원문 전체와 아키텍처 그림은 AWS Machine Learning Blog에서 볼 수 있습니다.