Case study · Agentic AI · Google Cloud AI
Enterprise AI that gets past the pilot
A 0→1 agent platform designed against the exact reasons enterprise AI stalls between a promising demo and real production.
The problem
Most enterprise improvement opportunities are invisible to the people who could act on them.
Large enterprises run AI pilots that look promising in demos but stall in production, blocked by unclear task boundaries, weak review before execution, poor visibility into tools and data, and workflows that do not fit real process and approval chains. The opportunities are real, but the evidence for them is scattered across tools and undocumented process, out of sight of the process owners, program managers, and leadership who could act. Forge is a 0→1 enterprise agent platform designed against those exact blockers.
Research
Six research threads converged into one product direction.
Process owners and operations leaders kept hitting the same barriers: official tooling did not reflect how work actually happened, success metrics were trapped in dashboards, communication loops took weeks, data residency blocked non-native solutions, and people wanted AI to advise, not act autonomously on critical changes.
Invisibility
Workarounds replace broken tools. People build their own because they cannot find the right info or workflow inside official tools.
Adaptive control
Not every problem needs an agent. High-risk tasks need deterministic UI; low-risk tasks accept a conversational flow.
Checkpoints
Delegation requires explicit checkpoints. People ask, “at what point can I intervene, at what point can I correct it.” Approval gates turn automation into collaboration.
Evidence
“This is amazing, if it’s right.” Excitement collapses into doubt without projected impact shown before commitment.
Reasoning
Every output must show the why. Without an audit trail, people refuse to delegate meaningful tasks.
Residency
Data cannot leave the enterprise. Residency requirements rule out non-native solutions; agents have to run where the data already lives.
The solution
From raw enterprise data to an agent a team is willing to ship.
Forge is not an agent builder, and that is deliberate. It produces the blueprint of the orchestrator and its subagents; the team reviews it, adjusts it, and takes it to a first-party or third-party platform of their choice to build and deploy.
Solution · 01
Turning enterprise data into something a process owner could mine.
Forge ingests the enterprise broadly: apps, tools, databases, connectors, bots, SOPs, and unstructured content such as chat, email, and meeting notes. The knowledge graph turns that material into a workflow and entity map, making a single business process legible enough to read, query, and mine for improvement candidates.
Fig. 01 · Knowledge graph. Enterprise data as a workflow and entity map.
Solution · 02
Surfacing opportunities, then proposing solutions side by side.
For each opportunity Forge surfaced, the process owner saw one or more proposed solutions. Some needed only a process tweak, no agent at all. Others called for a master agent orchestrating several subagents, delivered as a blueprint with instructions, tools, and boundaries already structured, so the team reviewed a recommendation instead of starting from a blank canvas.
Fig. 02 · An opportunity with proposed solutions side by side.
Solution · 03
Moving blueprint review from black box to inline collaboration.
Before a blueprint left Forge, process owners, operations leaders, and security reviewers needed a shared place to challenge logic and add approval gates. Comments stayed attached to the exact step, policy triggers were debated in context, and ownership could be assigned without leaving the editor.
Fig. 03 · Blueprint review. Comments and approval gates on the exact step.
Solution · 04
Showing the reasoning behind every recommendation.
Every opportunity and recommendation carried its rationale, tied to the operations problem it addressed and the data it came from, together with an impact projection simulated on past ingested data, so a reviewer could see the why before acting.
Fig. 04 · Opportunity detail. The rationale and the source data behind it.
The decisions
Two decisions defined the platform: where the map comes from, and who teaches the agent.
Forge is not an agent builder, and that is deliberate. It produces the blueprint of the orchestrator and its subagents; the team reviews it, adjusts it, and takes it to a first-party or third-party platform of their choice to build and deploy.
Decision A · The digital twin foundation
The enterprise map had to come from the people who do the work.
Forge is not an agent builder, and that is deliberate. It produces the blueprint of the orchestrator and its subagents; the team reviews it, adjusts it, and takes it to a first-party or third-party platform of their choice to build and deploy.
Path 1 · Centralized generation
A program owner with broad access enables connectors and the system generates the map automatically. Deployment is fast, visibility is immediate, savings opportunities show up quickly. The flaw: research with Fortune 100 customers showed that centralized data and official SOPs rarely match day-to-day operations, which run on hidden spreadsheets, local workarounds, and undocumented process. Automations built on that map break the moment they hit an undocumented reality. I had watched that failure pattern first-hand in earlier AppSheet automation work: one misidentified node halts a workflow and drags in constant manual intervention.
Path 2 · Distributed ground truth
A technical program manager initializes the foundation and delegates node mapping to domain experts inside each business unit, who build and verify their own sections against how work actually happens. Slower, more administrative friction, and harder cross-department permissioning under legal and privacy constraints.
The call · Path 2
I chose the distributed model. The probability of systemic failure in the centralized approach outweighed the friction of the distributed one. The honest cost, slower setup and heavier coordination, was accepted deliberately, and the delegation structure kept it bounded: one owner initializes the foundation, each expert fills in only the section they know. The result is a foundation agentic workflows can run on without breaking.
Fig. 05 · Early architecture artifacts. Process mapping wall and orchestration sketches.
Decision B · Permissions and learning
A reviewed feedback loop let field users teach the agent without breaking compliance.
Two personas with opposite profiles share the system. Program owners hold the governance responsibility, high technical expertise, and tight limits on what permissions they may distribute under compliance policy. Business users execute the workflows in the field, with deep domain context and lower technical expertise. The agent needs what only the field knows; policy restricts what the field may touch.
Path 1 · Strict restriction
Lock business users out of the training loop. Compliance holds, but the agent is cut off from the contextual field data it needs to improve. Edge case failures go uncorrected, the agent stays static, and the field user ends up burdened rather than assisted.
Path 2 · Broad access
Open configuration to field operators. The learning loop closes, but it violates enterprise policy and puts data governance and system integrity at risk.
The call · A third path
Neither was acceptable, so I designed a bridge: a semi-automated feedback loop and notification framework. Business users evaluate agent output inside their existing permission scope, and lightweight contextual feedback is captured during their normal workflow, translated into structured payloads, and routed to the program owner, who reviews and approves each micro-adjustment inside the secure environment. The agent improves continuously from field insight, vetted by governance, with compliance intact. The honest cost: field users never get direct configuration access, and improvements land with review latency rather than instantly. That loop is the one the monitoring surface in the next section displays.
Impact
Projected impact made the case for piloting. Measured impact made the case for scaling.
Forge ran simulations against past ingested data to project the business impact of each proposed solution over a defined window, giving leadership a concrete basis for the pilot decision and a baseline to measure real performance against. After rollout, the monitoring surface tracked business impact against that simulated baseline, while technical telemetry such as token use, API calls, and errors stayed on the platform where the agents were built. A self-monitoring loop learned from executions and surfaced new opportunities back into the queue, closing the improvement cycle the permissions decision made possible.
Fig. 06 · Monitoring surface. Business impact tracked against the projected baseline.
Specific projections, the measurement model, and the full interaction designs are covered in the complete case study, available on request.
What it shows
Enterprise AI earns adoption when
people can see it, check it, and measure it.
Forge was 0 to 1 work where research set the direction: six enterprise threads shaped what the platform became, and the two decisions above gave it a control layer. Positioning Forge as a blueprint, not a builder, let it sit on top of first-party and third-party agent ecosystems rather than compete with them, and the monitoring surface made agent fleets answerable to business goals rather than to demos.