I think every large enterprise is going to have its own AI harness.
Not necessarily a proprietary harness built from scratch. More likely, it will be an open core that the enterprise configures with its own identity systems, model gateways, internal tools, data sources, policies, approval processes, and audit requirements.
That harness could become the shared runtime behind a large part of the company’s internal AI work.
This matters because the current pattern does not scale well. A team wants an internal assistant, so it builds an application. Another team wants a policy search tool, so it builds a second application. Security wants a review tool. Support wants a ticket assistant. Engineering wants a code and Jira assistant. Each project ends up rebuilding some version of model access, authentication, connectors, permissions, logging, and policy checks.
After enough projects, the company has dozens or hundreds of small AI applications with overlapping infrastructure and different security assumptions.
I believe the enterprise harness is how we get out of that cycle.
I do not mean one giant chat window that replaces every internal application.
Teams will still build applications, workflows, command-line tools, and specialized interfaces. The difference is that those products can become thinner. Instead of every application building its own integration and governance layer, it can use a shared enterprise harness.
The harness becomes the place where the company standardizes the hard parts:
The applications sit above that shared layer.
Internal apps, developer tools, agents, and experiments
↓
Enterprise AI harness
┌─────────────────────────────────────────────────┐
│ Identity Model gateway Connectors Approvals │
│ Policy Security checks Audit Cost rules │
└─────────────────────────────────────────────────┘
↓
Jira Confluence GitHub ServiceNow Slack Data
This is the same reason enterprises standardize cloud platforms, identity providers, API gateways, and CI systems. A shared foundation reduces repeated work and gives security teams a consistent control point.
The plugin model is what makes this idea practical.
A generic open-source harness cannot know an enterprise’s internal project structure, risk model, cybersecurity policies, model providers, or approval process. It should not try to know them.
Instead, the enterprise adds plugins and providers for the capabilities it needs.
For example:
This is more useful than building a separate application for every combination of these capabilities.
Once the capability exists as a governed plugin, many internal applications can use it. A developer portal, a support workflow, a security review assistant, and a command-line tool might all use the same Jira connector and the same policy checks.
There is an important technical distinction here.
A plugin that reads company policy can help an employee understand the policy. It can answer questions, cite the source, show the effective date, and explain which review is required.
That is not the same as enforcing the policy.
Enforcement should be deterministic and external to the model. If the policy says only projects ENG
and SEC
are allowed, the harness should deny any other project through code or a policy-decision service. The model should not be asked to interpret its way around the rule.
In other words, an enterprise harness needs both:
This separation is one of the most important parts of the architecture. It gives employees useful context while keeping authorization outside the conversation.
They do not all disappear, and they should not.
A sales application and a cybersecurity review tool have different users, workflows, interfaces, and measures of success. They may still need separate products.
What can disappear is a large amount of duplicated backend work.
Each application should not need to invent its own way to:
With a shared harness, an application can focus on the job it was built to do.
This also changes experimentation. A team can test a new use case against mock connectors and audit-only policy. If the idea proves useful, it can move toward controlled access, approval-gated writes, and production monitoring without replacing the entire foundation.
The path from experiment to production becomes a profile and control change, not a full rewrite.
Imagine an engineer asks an internal tool to review a proposed service and open any required work items.
The application could use one shared harness to:
The user sees one coherent workflow. Underneath it, each capability has a narrow contract and a clear owner.
Security can maintain the policy and review plugins. The platform team can maintain identity, model routing, and audit. Application teams can compose those capabilities without copying them.
That is the part I find most interesting. The harness is not only a tool runner. It becomes a way to encode how the enterprise wants AI-enabled work to happen.
DeepSeek recently open-sourced its Harness. I cloned it, studied the Cordis plugin architecture, installed it locally, and built an enterprise suite on top of it.
The technical milestone is not simply that another coding agent is available. The important part is that the harness itself is open and composable.
An enterprise can inspect the runtime, build its own plugins, create different profiles, replace providers, and keep internal controls outside a vendor-managed black box. That makes it possible to test this enterprise-harness model with real code today.
I released my implementation as the DeepSeek Harness Enterprise Suite.
The first release composes three plugin roles:
DeepSeek Harness profile
├─ enterprise-atlassian
├─ enterprise-policy
└─ enterprise-audit
A protected tool request follows this path:
Tool request
→ validate arguments
→ evaluate policy
→ apply project, space, and DLP guards
→ request approval when required
→ resolve credentials
→ call the enterprise API
→ validate the structured result
→ verify the outcome
→ record the final redacted audit event
Connectors do not decide enterprise authorization. Policy plugins do not hold vendor credentials. Audit observes the final outcome rather than the agent’s original intention.
That separation lets an enterprise replace any layer without rewriting every tool.
Version 0.1.0
currently provides:
The suite starts in mock mode. Installing it cannot modify a real Atlassian tenant until an operator explicitly enables live mode and configures credential references.
From a DeepSeek Harness source checkout:
export DSH_HOME=/absolute/path/to/an/evaluation-home
pnpm dsh plugin --profile web add github:mickymultani/deepseek-harness-enterprise-suite#v0.1.0
pnpm dsh --profile web --dump-config
pnpm dsh web --no-open
To scaffold a new connector project:
npx dsh-enterprise-suite create-dsh-enterprise-plugin knowledge-search
The roadmap covers more than application connectors.
It includes identity propagation, Vault and cloud secret providers, OPA and Cedar policy decisions, model gateways, OpenTelemetry, SIEM export, enterprise search, ServiceNow, GitHub Enterprise, security operations, cloud controls, legal, privacy, vendor risk, finance, HR, and customer support.
The order matters:
A connector that can call an API is not automatically ready for enterprise production. It also needs ownership, authorization, data handling, failure behavior, testing, audit, and incident procedures.
If this pattern works, enterprises gain more than technical reuse.
They gain a standard place to answer important questions:
That gives platform, security, risk, and application teams a common surface.
It also gives leadership a clearer view of experimentation. Instead of discovering untracked applications after they are already in use, the company can provide a supported path for teams to build and test ideas with approved models, connectors, and controls.
I think open, plugin-based harnesses will become a standard part of the enterprise technology stack.
Companies will not all use the same plugins or policies. That is the point. Each enterprise will shape the harness around its own systems, risk tolerance, regulatory obligations, and ways of working.
The shared core provides the runtime. The internal plugins make it the company’s runtime.
That is why I see the open-sourcing of DeepSeek Harness as a meaningful milestone for enterprise AI. It creates a practical foundation for moving from scattered experiments and duplicated internal applications toward a governed, reusable platform.
The project is open source under the MIT license:
github.com/mickymultani/deepseek-harness-enterprise-suite
I would like to hear how other platform, security, and engineering teams see this. Will enterprises converge on one internal harness? Which capabilities need to be standardized first? And where should the boundary sit between the shared harness and the applications built on top of it?