Navigate this article
Marketing prepares campaigns, finance checks documents, and sales follows opportunities. As teams adopt AI, the question becomes more than choosing a model. The business needs a way to organize access to information, execution of actions, and improvements across teams.
A domain is the work a team is responsible for
A domain brings together processes, vocabulary, data, responsibilities, and business rules. Marketing and finance may use the same model, but should not inherit the same tools, information, or permissions.
Here, a domain-specific harness means an execution system adapted to that context. It connects models to systems, supplies relevant references, checks permissions, and tracks outcomes. It is not just a prompt, chatbot, or automation sequence. Those can be parts of the environment without replacing its controls.
Share the foundation, not every permission
The shared foundation can provide identity, approved connectors, version records, cost limits, and execution monitoring. Each domain then defines its knowledge sources, tools, owners, and quality criteria.
Teams can work through different approved models and interfaces. Flexibility means choosing what fits the task while access rules remain enforced by the service executing the action. An MCP connector exposes tools; it does not establish authorization, quality, or governance on its own.
- Shared foundation: authentication, isolation, secrets, records, and execution limits.
- Per domain: sources, allowed tools, policies, and the process owner's approval.
- Per task: objective, required data, expected outcome, and stopping criteria.
The harness only enforces controls on integrated paths. Personal accounts, copied data, and external tools are not automatically monitored. Those uses also require internal policies, guidance, and access management.
Marketing: from information to a reviewed campaign
A team can consult the approved catalog, brand guidance, and aggregate metrics to prepare a brief and campaign variations. AI returns drafts with references; a responsible person retains publishing authority.
The harness limits sources, avoids unnecessary customer data access, and separates drafting from publishing or buying media. Tests check whether claims have sources, offers are current, and nothing is published without approval. Review time and corrections help assess usefulness.
The cases in this guide are illustrative applications, not client reports or results already achieved.
Finance: reconcile before deciding
An assistant compares authorized documents and entries, flags discrepancies, and prepares a review list. Every finding should lead back to its source record rather than presenting an unexplained number.
Initial access is read-only and limited to the authorized company and period. Preparing an analysis does not authorize changing entries or issuing payments. Compare detected discrepancies, false alerts, and missed records with a sample reviewed by finance. Calculations and accounting rules need validation independent of generated text.
Sales: prepare a proposal without inventing terms
Starting from a CRM opportunity, AI gathers permitted history, looks up current prices, and drafts a proposal. Sales reviews the terms and next steps before sending it.
The system validates account access, price list version, and discount limits. Sending the proposal is a separate action tied to approval of that version. Test expired prices, out-of-policy discounts, and accounts belonging to another team. Track corrections and time to an approved proposal, not just text generation speed.
Support and operations: resolve and route
In support, an order lookup can produce a reply draft and route an exception. In internal operations, a request can be classified and sent to its owner. History, current state, and process policy provide context.
Reading, replying, changing a record, and issuing a refund are distinct permissions. Missing information or tool failure needs a clear stop or escalation path. Test repeated attempts, outages, and requests to ignore rules. Measure correct resolution, duplicate actions, and unnecessary handoffs.
Give teams a path to propose improvements
People who know the operation should be able to describe a task and suggest an improvement without building the whole infrastructure. That does not mean publishing any agent directly to production. A shared path makes proposals comparable and ownership visible.
- Describe: the problem, owner, required data, and expected behavior.
- Experiment: use fictional or minimized data in an isolated environment.
- Evaluate: compare with the current process, including failures and expected refusals.
- Approve: review access, risks, and evidence with the process owner.
- Release: record versions of instructions, tools, policies, and tests.
- Monitor: track cost, errors, and human corrections; retain the ability to pause or roll back.
Execution records also need restricted access, secret removal, and a retention period. Do not copy sensitive conversations and documents into logs by default.
Where software engineering fits
Engineering builds and maintains the foundation: system integrations, tool contracts, authorization outside the model, environment separation, evaluation, and recovery. That includes choosing a deterministic rule or simple workflow when it solves the task better than an agent.
The domain owner defines a correct delivery and who may approve it. Security and privacy specialists participate according to risk. Autonomy grows per task and through evidence, not by granting the model broad access.
Start with one team and one task
Choose a frequent, reversible task with an available owner: preparing a referenced brief, checking discrepancies, or drafting a proposal. Record how it works today and which failures would be unacceptable.
The first outcome should be a testable workflow: tool contracts, a permissions map, a case set, and a review report. Validate that delivery before expanding autonomy or bringing the shared foundation to another domain.
Sources and further reading
Educational material. Validate examples in a test environment and adapt decisions to your project's context, risks, and responsibilities.
Share