Skip to content
About

We build the layer between AI agents and the software professionals actually use

DCCMCP started from a specific frustration: AI agents are extraordinary at reasoning about geometry, models and maps, and terrible at operating the applications those things live in. The model is not the bottleneck. The interface is.

So we build that interface properly — typed tools, safety policies, checkpoints, audit trails and version support — for the software that runs real production work in 3D, CAD, GIS and computer vision.

Principles

Four beliefs that shape what we ship

These are the positions we would defend in a technical review, and the reasons some features are deliberately not on our roadmap.
01

Automation must be reversible

If an operation cannot be undone, it should not be available to an agent without a human in the loop. We treat reversibility as a product requirement, not a feature flag.

02

The record matters as much as the result

Deliverables get reviewed, but the process behind them gets audited. A tool call that cannot be explained six months later is a liability, however good the output was.

03

Local first, always

Studio work is confidential by nature. The default architecture keeps your data on your hardware, and remote deployment is a deliberate choice rather than the only option.

04

Vendors ship updates; we absorb them

Host applications change constantly. Maintaining version support is unglamorous, ongoing work — and it is the difference between a demo and something a studio can rely on.

Independence

An independent integration vendor, on purpose

We are not a vendor's internal team and we do not pretend to be one. That independence is what lets us support several applications with one consistent contract — and to say plainly when something is not officially supported.

How we work with vendors

  • We integrate through documented, public APIs and follow each project's license terms.
  • We do not use vendor logos as our branding, and we state clearly that integrations are third-party.
  • We report bugs upstream when we find them, and we keep our own compatibility matrix honest when a vendor changes something.
  • Where we build on open-source components, we credit them and separate the open-source and commercial parts of our product clearly.
Read the third-party notice

Working on a pipeline that needs this?

We are hiring people who have shipped tooling for studios or engineering teams — and we are onboarding design partners who want to shape what ships first.