Chief AI Architect Approaches – Prompt Engineering: An Operating Model for Enterprise Engineering Teams

AI & ML & Blockchain, AI Engineering, AWS, Azure, Blog, Cloud, CXO, Enterprise Architecture, Experiences (All IT), IT Transformation, Java, Scala, All IT, What I Have Learned Today

In a large enterprise you are a Chief AI Architect or AI Advocate.

Consider, your enterprise business services and capabilities includes Customer Onboarding, Customer Account Management, Customer Products Search, Customer Orders, Customer Billing, Customer Subscriptions and more.

Consider your enterprise modernized their legacy systems with Microservices, BFF, Event Driven Architecture, Agentic AI solutions for Customer Support and Internal Developer SRE activities.

Now, imagine in your enterprise there are 100 engineering teams managing around 1,000 business applications (assume 40 years old enterpise) and business services across their tech ecosystem such as:

Spring Boot • .Net • NodeJS • Python • AWS • Azure AKS • MongoDB ATLAS • PostgreSQL • Redis • DataDog • Drools • Shopify Hydrogen • AWS Kinesis • AWS Kafka • Azure Event Hubs • OnPrem Apache Kafka • Azure Key Vault • Azure Cosmos DB • AWS DynamoDB 

Now add Claude Code, GitHub Copilot, Codex, Cursor, VS Code, and other AI-assisted engineering tools.

The challenge is no longer:

How do we write better prompts?

It becomes:

How do we make prompt engineering repeatable across teams, technologies, services, and AI harnesses?

As a Solutions Advocate, I would approach this as an operating model, not a collection of prompts.

Table of Contents

  1. Prompt Engineering

  2. Here Comes the Chief AI Architect Approach: “Prompt Engineering Operating Model”

  3. Define the Prompt Engineering Operating Model

  4. Create One Enterprise Digital Platform AI Skills Capability

  5. Package Once, Install Once

  6. Put .digital-platform-ai/ in Every Service Git Repository

  7. Keep the Developer Experience Simple

  8. Let the Skill Drive the Investigation

  9. The Complete Operating Model

Prompt Engineering

Factors to consider – effort, adaptive thinking defaults, tool use,

General principles

  • Give LLM a role

  • Use precise and direct prompts

  • Long context prompting – Put longform data at the top

Tool use

  • Optimize parallel tool calling

Thinking and reasoning

  • Consider moving to adaptive thinking

    • (adaptive thinking ‘vs’ extended thinking)

  • Minimizing hallucinations in agentic coding (<investigate_before_answering>)

Model-specific guidance

  • Response length and verbosity

  • Calibrating effort and thinking depth (max > xhigh > high > medium > low)

  • Tool use triggering

Here Comes the Chief AI Architect Approach: “Prompt Engineering Operating Model”

The techniques above work for individual AI interactions. At enterprise scale, we should not expect every engineer to remember, recreate, and maintain them independently.

Instead, we can turn these practices into a Prompt Engineering Operating Model and embed them into reusable Enterprise Digital Platform AI Skills.

1. Define the Prompt Engineering Operating Model

A Prompt Engineering Operating Model defines how AI is instructed, how context and reasoning are managed, when tools are used, how investigations execute, and how conclusions are verified.

Control Engineering Standard
Instructions Role, objective, scope, constraints, and expected outcome
Context Provide relevant application and runtime context
Reasoning Match reasoning effort to task complexity
Tools Retrieve code, configuration, logs, traces, metrics, and runtime state
Execution Parallelize independent calls; sequence dependent calls
Verification Investigate before answering; distinguish evidence, inference, and unknowns

The objective is to turn prompt-engineering practices into repeatable engineering behavior.

2. Create One Enterprise Digital Platform AI Skills Capability

Create one centrally governed Git repository:

enterprise-digital-platform-services-ai-skills

The repository provides reusable standards and skills across the Digital Platform technology ecosystem.

enterprise-digital-platform-services-ai-skills/
├── standards/
│   ├── prompting/
│   ├── reasoning/
│   ├── tool-use/
│   └── verification/
├── skills/
│   ├── spring-boot/
│   ├── python/
│   ├── aks/
│   ├── datadog/
│   ├── postgres/
│   ├── mongodb/
│   ├── redis/
│   ├── kafka/
│   ├── eventhub/
│   ├── keyvault/
│   ├── cosmosdb/
│   ├── drools/
│   └── shopify-hydrogen/
└── harnesses/
    ├── claude-code/
    ├── copilot/
    ├── codex/
    ├── cursor/
    └── vscode/

Enterprise Digital Platform AI Skills define HOW AI works with our technologies.

A Redis skill knows how to investigate Redis. A DataDog skill knows how to investigate logs and traces. An AKS skill knows how to investigate deployments.

Those reusable skills should not hard-code the architecture of 1,000 individual services.

3. Package Once, Install Once

Package and version the Enterprise Digital Platform AI Skills centrally.

npm install -g @enterprise/digital-platform-services-ai-skills

A simple Confluence page can document installation, configuration, upgrades, supported AI harnesses, and examples.

The skills are installed once on the developer machine, rather than copied and independently maintained across hundreds of service repositories.

Engineers can continue using their preferred environment:

Claude Code • GitHub Copilot • Codex • Cursor • VS Code • other supported harnesses

Standardize the capability, not the AI client.

4. Put .digital-platform-ai/ in Every Service Git Repository

Enterprise Digital Platform AI Skills know HOW to investigate.

But every service is different. The AI also needs to know:

  • What service is this?

  • What technology does it use?

  • Where is its -ops repository?

  • What services does it depend on?

  • What databases, caches, and messaging platforms does it use?

  • Which environments exist?

  • Where are its logs and traces?

  • How does it authenticate to dependent APIs?

Therefore, every service Git repository contains a .digital-platform-ai/ folder.

For example:

checkout-service/
├── src/
├── pom.xml
├── README.md
└── .digital-platform-ai/
    ├── service.yaml
    ├── dependencies.yaml
    ├── environments.yaml
    ├── authentication.yaml
    ├── observability.yaml
    ├── ServiceInstructions-01.md
    ├── ServiceInstructions-02.md
    └── ServiceInstructions-03.md

Use a mix of YAML and Markdown.

YAML for Configuration and Facts

YAML provides predictable, machine-readable service metadata.

# service.yaml

service:
  name: checkout-service
  technology: spring-boot
  owner: checkout-team

repositories:
  application: checkout-service
  operations: checkout-service-ops

runtime:
  platform: aks

dependencies.yaml can describe dependent APIs, PostgreSQL, MongoDB, Redis, Kafka, Event Hubs, or other resources.

authentication.yaml can reference Azure Key Vault:

# authentication.yaml

authentication:
  type: oauth2
  credentialSource: azure-key-vault
  keyVault: checkout-kv

  secrets:
    clientIdRef: checkout-client-id
    clientSecretRef: checkout-client-secret

The Git repository contains references, not credentials. Client secrets, passwords, JWTs, and access tokens stay outside Git and are retrieved or generated only when authorized and required.

Markdown for Service-Specific Instructions

Numbered Markdown files provide instructions specific to the service:

ServiceInstructions-01.md — application architecture and request flow
ServiceInstructions-02.md — diagnostic and troubleshooting instructions
ServiceInstructions-03.md — dependencies and authentication instructions

Teams can extend this incrementally with ServiceInstructions-04.md, ServiceInstructions-05.md, and so on.

For example, diagnostic instructions can tell the AI to inspect the application repository and -ops repository, identify the AKS environment, retrieve DataDog logs and traces, correlate request IDs, follow downstream dependencies, and investigate before identifying a root cause.

The convention is simple:

YAML provides configuration and facts. Markdown provides service-specific instructions.

5. Keep the Developer Experience Simple

An engineer working on checkout-service opens the service repository and starts their preferred AI harness:

cd checkout-service
claude

They can invoke reusable Enterprise Digital Platform AI skills such as:

/trace-request • /diagnose-failure • /analyze-query • /diagnose-aks • /analyze-redis • /analyze-deployment

The AI now combines three sources:

Source Provides
Enterprise Digital Platform AI Skill Reusable engineering capability — HOW
.digital-platform-ai/ Service configuration, dependencies, references, and instructions — WHAT / WHERE
Current Service Repository + Runtime Actual code and operational evidence

The engineer no longer needs to repeatedly explain that the service runs on AKS, calls pricing-service, uses Redis and PostgreSQL, has a separate checkout-service-ops repository, uses DataDog, or obtains API credentials through Key Vault.

The service already describes that context.

6. Let the Skill Drive the Investigation

Consider an engineer running /diagnose-failure.

The skill first reads .digital-platform-ai/ to understand the service. It can then inspect the application repository, -ops repository, AKS, and DataDog, and follow evidence into Redis, PostgreSQL, MongoDB, Kafka, Event Hubs, Key Vault, or dependent services.

This is where our original prompt-engineering principles become operational:

  • Tool use retrieves actual engineering evidence.

  • Parallel tool calling investigates independent sources concurrently.

  • Adaptive thinking allows reasoning effort to match problem complexity.

  • Tool triggering determines when runtime information is required.

  • Response verbosity remains independent from reasoning depth.

  • <investigate_before_answering> reduces unsupported conclusions.

For example, finding a RedisTimeoutException in DataDog is evidence of a timeout. It is not automatically evidence that Redis is the root cause.

Confidence is not evidence. If the answer depends on runtime reality, retrieve runtime reality.

7. The Complete Operating Model

The approach ultimately has three layers:

Layer Responsibility
Enterprise Digital Platform AI Skills HOW — reusable capabilities for Spring Boot, Python, AKS, DataDog, databases, messaging, security, and other technologies
.digital-platform-ai/ in every service Git repository WHAT / WHERE / INSTRUCTIONS — service metadata, dependencies, -ops repo, environments, observability, authentication references, and service-specific instructions
Application + Runtime EVIDENCE — code, configuration, logs, traces, metrics, deployments, and runtime state

For an organization managing approximately 1,000 applications and services, we should not create 1,000 independent prompt strategies.

One Prompt Engineering Operating Model + reusable Enterprise Digital Platform AI Skills + a standardized .digital-platform-ai/ folder in every service Git repository + the AI harnesses engineers already use.

That is how prompt engineering moves from individual developer experimentation to a repeatable enterprise engineering capability.

Post Views: 147