How OMS Changed the Way It Works, from OMS to Claude AI

The OMS team, in an environment where 4 people operate 12 MSAs, redesigned its way of working around Claude Code (v2.0.72, Opus 4.5). As the number of MSAs grew, problems such as grasping impact scope, missing code-level policies, uneven understanding within the team, and increasing deployment requests became bigger, and to solve this, AI was turned into a shared, team-wide productivity tool.

The core change was standardizing the AI usage that had varied from person to person into role-based Context. By dividing roles into PO, TPM, Backend, Frontend, and Infra, and having each role load only the documents it needs, the AI's scope of responsibility and level of answers were made clear from the start of the session. The TPM AI looks at the overall architecture and impact scope and splits work into sub Jira issues, while the MSA AI focuses on the relevant issue down to the code level, handling development and spec updates.

The key underpinning this structure is the separation between .claude/ai-context/ and skills/.

• ai-context/ holds static knowledge such as domain-overview, data-model, api-spec.json, kafka-spec.json, and external-integration.md.
• skills/ defines behavioral workflows like develop and deploy.
• Knowledge is explicitly loaded at the start of a session, while behaviors are only invoked when needed, making token usage and loading timing predictable.

API and Kafka specs were structured as a JSON-form DSL instead of natural language. This makes it possible to see endpoints, request/response, use cases, domains, and external calls at a glance, allowing the TPM AI to quickly trace call maps and integration relationships across multiple MSAs. When answers were wrong, question-and-answer and feedback were repeated to keep reinforcing the ai-context, raising the quality of learning.

MCP integration was also central to work automation.

• Atlassian MCP was connected to Jira/Confluence to automate requirement analysis, sub-ticket creation, and progress sharing.
• Github MCP handled PR reviews, production deployment preparation, and tag creation.
• Datadog MCP was used to check pre- and post-deployment impact along with real-time Trace and logs in natural language.

On the architecture side, the team concluded that clean architecture is most favorable for AI Context. A layered structure has a lot of unnecessary code noise, but a structure with separated UseCase/Port/Adapter is easier for AI to read since it narrows down to only the necessary responsibilities, raising both token efficiency and accuracy. As a result, the team's collaboration structure changed so that PMs hand off initial analysis to AI and focus on more essential decision-making, while engineers spend more time on design and review than on simple implementation.