CRM Prototype Studio

A prototype for moving from business requirement to reviewable solution artifacts across CRM, data and integration platforms — with deterministic generation, testing, version control and explicit human approval.

The question

AI-assisted development is often discussed as a productivity story: generate some code, create a configuration or draft an integration faster. That is useful, but enterprise delivery raises a harder question:

What would it take for AI-assisted delivery to become a controlled engineering capability rather than an increasingly powerful collection of shortcuts?

I wanted to make that question concrete. The experiment became CRM Prototype Studio: a small orchestration layer that takes a business requirement, interprets it, produces a deployment plan and moves through reviewable stages across CRM, data and integration platforms.

What I built

The prototype connected a requirement-driven workflow across a small Salesforce and Snowflake environment. Rather than allowing an AI model to make arbitrary changes directly, the workflow separated interpretation, generation, validation and deployment authority.

At a high level, the pattern looked like this:

AI can reason about the solution, but controlled delivery still depends on deterministic artifacts, validation evidence and explicit deployment authority.

The important boundary: AI proposes, engineering executes

The most useful architectural decision in the prototype was not which model to use. It was deciding where probabilistic reasoning should stop.

The model could interpret requirements, identify likely solution patterns and propose an execution plan. But the actual platform changes were produced through deterministic generators and known deployment mechanisms.

This creates a cleaner separation:

• AI interprets and proposes.
• Generators create repeatable artifacts.
• Tests establish evidence.
• Humans retain deployment authority.

That separation reduces the temptation to give an increasingly capable model unrestricted authority simply because it can technically perform the action.

Approval needs to approve something specific

A generic “human in the loop” statement sounds reassuring but can be architecturally weak. What exactly is the person approving?

The prototype therefore moved toward the idea of an approval fingerprint: the human approves a specific plan, set of target resources and generated artifacts. If the plan changes materially after approval, the previous approval should no longer be considered valid.

That turns approval from a ceremonial click into a control boundary.

Preflight became more important than generation

It is easy to focus on whether AI can generate a Salesforce configuration or Snowflake change. In practice, environment readiness became just as important.

Before a deployment can be trusted, the workflow needs to know whether the target environment is reachable, whether credentials are valid, whether required services exist and whether the identity executing the change has the expected permissions.

That led to a connected read-only preflight stage. The workflow could verify Salesforce and Snowflake connectivity without making changes. If preflight failed, deployment remained blocked.

That may sound mundane, but it is exactly the sort of control that separates a compelling demo from something that could eventually fit into an enterprise engineering process.

Validation before deployment

The prototype also introduced a dry-run pattern in which the plan could move through validation without performing external delivery.

For example:

• Snowflake changes could run through validation logic.
• Salesforce configuration could be checked against the connected environment.
• External delivery could remain simulation-only.
• Evidence could be collected before asking for deployment approval.

This creates a much stronger conversation with reviewers than “the AI thinks this will work.”

The workflow can instead say: this is the proposed change, this is the environment we checked, and this is the evidence produced before deployment.

Git became part of the control plane

Version control was useful for more than storing source code. It became the place where generated artifacts, manifests, plans and evidence could be associated with an immutable point in time.

That matters because AI-assisted engineering creates a traceability problem. If an artefact was generated from a requirement, modified through a model-driven workflow and approved by a human, the organisation needs a way to reconstruct what happened later.

Git gives us one piece of that answer:

requirement → generated artifacts → validation evidence → approval → deployed version

The model conversation itself is not enough. The engineering record needs to survive independently of the model session.

The architecture implication: an agent control plane

As the prototype evolved, I stopped thinking of it simply as an AI development assistant. A more interesting pattern was emerging.

An enterprise agent needs boundaries around:

• identity;
• permissions;
• available tools;
• target environments;
• policy;
• approval;
• evidence;
• observability;
• deployment authority.

Together those controls start to resemble an agent control plane.

The model is one component. The architecture around the model determines what it is allowed to know, propose and change.

Why this matters beyond software development

Although the prototype used CRM, Snowflake and deployment workflows, the pattern is much broader.

The same architecture question appears whenever an enterprise agent can take meaningful action: resolving a customer issue, adjusting an operational process, changing data, initiating a financial transaction or coordinating other agents.

The more capable the agent becomes, the less sufficient “human in the loop” becomes as a governance strategy. Enterprises need explicit control boundaries and observable evidence.

What I would do next

A production-oriented version would strengthen the control plane rather than simply adding more model capability. I would focus on policy evaluation, workload identity, short-lived credentials, approval binding, evidence retention and environment-specific deployment authority.

I would also separate the orchestration layer from individual technology adapters so new platforms could be added without changing the governance model.

What I learned

The experiment started as a question about AI-assisted delivery speed. It ended up reinforcing a more useful architecture lesson:

The difficult part of enterprise agentic AI is unlikely to be getting the model to perform an action. The difficult part is designing the system that decides when that action is allowed, proves what happened and retains human authority where it matters.

That is the direction I want to keep exploring in the Architecture Lab: not simply whether AI can do more, but how enterprises can let it do more without giving up engineering discipline.