Як DXC будує OASIS на Claude для mission-critical enterprise systems

DXC десятиліттями керує системами банків, авіакомпаній, страховиків, manufacturers і державних організацій. Це середовище з legacy code, strict change windows, audit, segregation of duties і довгими operational runbooks. У квітні 2026 DXC запустила OASIS — AI-native orchestration platform для managed services, де агенти беруть значну частину routine work.

Claude став default foundation model для OASIS agentic workflows. Цінність кейсу не в «агенті замість адміністратора», а в тому, що automation вбудовується у managed-service control plane: context, tools, approvals, engineering review і production evidence залишаються частиною системи.

Trigger може бути service ticket, incident, maintenance request, modernization backlog або security signal. Input — CMDB/system metadata, approved runbooks, code/repository context, logs, policy, customer-specific constraints. Claude виконує reasoning, planning, code transformation або security analysis; OASIS/tool layer виконує дозволені reads/writes у конкретних enterprise systems.

Для reproduction варто використовувати flow `event → identity/context → evidence collection → plan → policy/authority check → bounded tool call → authoritative postcondition → result/escalation`. Модель не повинна мати implicit permission лише тому, що вона правильно класифікувала incident. Authorization перевіряється на кожній consequential action.

• Trigger → ticket, incident, backlog item або security finding;
• Input → customer context, runbook, system state, code/logs, policy;
• AI stage → classify, reason, plan, generate/refactor, propose remediation;
• Integrations → repo/CI, ITSM, observability, security tools, application-management systems;
• Output → verified change/PR/runbook result або escalation bundle;
• HITL → risk-based approval для protected systems і production changes.

DXC повідомляє дві різні речі, які легко змішати. Перша: Claude був основним tool для створення OASIS; понад 95% коду, за оцінкою DXC, generated by Claude і reviewed engineers, а development нібито прискорився приблизно у 10 разів. Друга: уже запущений OASIS використовує Claude як default foundation model для agentic workflows.

Ці loops потребують різних controls. Coding loop — branch, tests, PR, CI, review, merge, deploy. Runtime loop — identity, tool scope, approval, idempotency, postcondition, incident recovery. Змішувати їх в один KPI «95% automated» — чудовий спосіб втратити розуміння, що саме система робить і хто за це відповідає.

Кейс класифікуємо A3: public evidence підтверджує agentic routine work, але не A5 authority над mission-critical systems. У regulated operations варто мати tiers: read-only diagnosis; draft/proposed change; reversible low-risk execution; high-impact change з explicit approval; prohibited actions.

Approval має бути bound до exact action payload, target resource, environment, evidence snapshot і expiry. Якщо plan змінився після approval, потрібне повторне підтвердження. Інакше human-in-the-loop перетворюється на checkbox, що юридично існує, а технічно нічого не контролює.

Managed services мають класичні distributed-system failures: API timeout після успішного write, частково застосована config, stale CMDB, concurrent human change, rollback dependency, duplicate ticket або reused approval. Agent runtime повинен спочатку reconcile authoritative state, а не повторювати mutating call навмання.

Multi-customer environment додає tenant isolation: credentials, logs, runbooks і retrieval corpus мають scoped identity. Context із одного customer не може стати instruction/evidence для іншого. Tool result вважається untrusted data, поки policy layer не підтвердить source і scope.

Anthropic повідомляє, що DXC оцінює development acceleration приблизно у 10×, понад 95% коду OASIS generated by Claude з engineering review, а OASIS уже працює більш ніж для 50 customers. Це сильні deployment signals, але джерело — партнерське оголошення Anthropic з estimates DXC.

Для власної програми KPI мають бути outcome-based: accepted change lead time, first-pass CI rate, escaped incidents, rollback rate, MTTR, human review minutes, unauthorized-action rate, cost per verified task і частка tasks, що завершуються authoritative postcondition. Code-generation share сама по собі нічого не каже про quality.

OASIS-подібний layer працює постійно: tickets, incidents, maintenance і security events приходять без красивих пауз між demo. Масштабування означає queueing, concurrency limits per customer/system, workload budgets, downstream rate limits і reviewer capacity. Один global agent з глобальним credential set — не scale architecture, а майбутня глава incident report.

Cost model: model usage + orchestration/runtime + connectors + sandbox/CI + observability + evaluation + human approval + incident reserve. Requirements: mature identity/RBAC, authoritative CMDB/state sources, tool registry, versioned runbooks, deterministic CI/postconditions, audit logs і rollback procedures.

Почніть з одного high-volume low-blast-radius job: наприклад, collect diagnostics → map to runbook → propose change → execute read-only verification. Зберіть 50–200 historical tickets із known resolution, replay їх offline і виміряйте decision + tool trajectory, а не лише фінальний текст.

Після стабільного draft/read-only режиму додайте reversible action з idempotency та postcondition. Лише потім — canary на subset customers. Shared primitives identity, approval, trace, evals і rollback повинні повторно використовуватися наступним agent workflow; якщо кожен use case будує свою governance систему, ви масштабуєте хаос, а не AI.

• Вибрати один bounded operational job і system owner.
• Зібрати historical eval set та baseline cost/lead time.
• Запустити read-only/draft agent з повним trace.
• Додати per-action authorization, idempotency і postconditions.
• Canary на low-risk tenant/system subset із rollback drill.
• Масштабувати тільки після quality, incident і reviewer-capacity gates.