# How enterprise AI gets approved engineering context
> Enterprise AI coding agents need the ticket, design note, and conversation behind a change, under the same access rules as the code. Learn how to pilot approved context, what Nav reported, and how Factory connects sources and enforces controls.
URL: https://factory.com/articles/regulated-engineering-context
Published: 2026-09-24
Updated: 2026-10-23
Enterprise AI produces useful engineering work when an agent can reach the ticket, design decision, and conversation behind a change through the same approved access that governs the code. Connect those sources with credentials your security team approves, keep merge approval in the systems that already enforce it, and measure context-gathering time before and after.
Adoption often stalls before an agent writes a useful patch. The repository contains the implementation, while the reason for changing it lives somewhere else. Engineers still have to connect those sources under the organization's access rules.
[Nav's published case study](https://factory.com/case-studies/nav) describes that problem across on-premises GitLab, Confluence, Jira, and Slack. Nav reported a 60% reduction in context-switching time and twice-as-fast feature development cycles after adopting Factory. These are customer-reported outcomes, not a controlled benchmark or a forecast for another team.
CTO Gian Perrone describes the security requirement directly:
> "Factory provided us with a secure, controlled way to unify our engineering context without compromising our compliance requirements."
## Give the agent the reason behind a change
Consider a modification to a financial integration. The code describes today's behavior. A ticket explains the requested change. A design decision may explain why an apparently simpler implementation was rejected. Supplying only the repository forces the agent or its reviewer to rediscover the missing context.
The diagram shows the path the context should take, from each source through an approved connection to a pull request that a human still approves.
Code
self-managed Git"]
B["Tickets and design docs
requirements and past decisions"]
C["Team conversations
context behind the request"]
D["Approved connection
MCP server or Connector, scoped credentials"]
E["Droid
plans and writes the change"]
F["Pull request
requirement, preserved behavior, evidence"]
G["Existing merge approval
owners and branch rules"]
A --> D
B --> D
C --> D
D --> E --> F --> G
`}
/>
Make one acceptance criterion the quality of the resulting explanation. A useful patch identifies the requirement it satisfies, the behavior it preserves, and the evidence that validation passed. Faster code generation without that record can move work from the implementer to the reviewer.
## Run a pilot that measures context
Start a pilot with a real change that spans those sources. Record how long an engineer normally spends gathering the relevant material, resolving access problems, and explaining it to a reviewer. That baseline makes context retrieval visible instead of burying it inside a broad productivity number.
The table lists what to record before and during the pilot.
| Measure | What to record |
| --- | --- |
| Context gathering | Time spent finding tickets, documents, and threads |
| Access interruptions | Requests blocked or delayed by permissions |
| Accepted changes | Pull requests merged without major rework |
| Reviewer corrections | Comments that supply missing background |
Evaluate these together. The goal is a workflow that reaches a reviewed result with less manual reconstruction of the background.
## Make the deployment choice explicit
Nav's story was published before the Factory Private launch. It supports the value of approved context access, but it does not establish that Nav deployed the newly launched Private product.
For organizations making that choice now, the deployment decision still belongs to the organization's own evidence, contracts, and operating requirements. Decide where the control plane, inference, runtime, and retained evidence belong. Do not infer the answer from the location of the Git server alone.
## How Factory connects and controls engineering context
Factory is a platform for running a software factory, where agents called Droids take work from a signal to a reviewed pull request. For regulated teams, the parts that matter are how Droid reaches each source and who controls that access.
**Approved connections.** Factory's [MCP documentation](https://docs.factory.com/harness/mcp) describes how Droid connects to external tools and data sources over local or remote transports. For supported cloud apps, [Connectors](https://docs.factory.com/harness/connectors) add guided authentication, and when an organization manages connector availability only apps an Owner or Manager enabled appear. The integration must still run with approved credentials and permissions.
**Organization controls.** [Enterprise Controls](https://docs.factory.com/enterprise/hierarchical-settings-and-org-control) govern models, tools, safety policies, and network restrictions across laptops, CI, VMs, and airgapped environments. The org `modelPolicy` allowlist decides which models exist at all, and `mcpPolicy` sets MCP policy. Keep source permissions and merge approval requirements in the systems that already enforce them. An agent's instruction to be careful cannot replace those controls.
**Deployment patterns.** [Factory's deployment patterns](https://docs.factory.com/enterprise/network-and-deployment) distinguish cloud-managed, hybrid, and fully airgapped operation, and each pattern can restrict outbound hosts and route LLM traffic through a central gateway you monitor.
## Frequently asked questions
### What is approved engineering context?
Approved engineering context is the code, tickets, design documents, and conversations behind a change, made available to an AI agent through credentials and permissions the organization has approved. Access to a source should not imply access to every document or action it exposes.
### What did Nav report after adopting Factory?
Nav reported a 60% reduction in context-switching time and twice-as-fast feature development cycles. These are customer-reported outcomes from its published case study, not a controlled benchmark or a forecast for another team.
### How does Droid connect to tools outside the repository?
Droid connects to external tools and data sources through MCP servers, or through Connectors for supported cloud apps. When an organization manages connector availability, only apps an Owner or Manager enabled appear.
### Which deployment pattern should a regulated team choose?
Factory documents cloud-managed, hybrid, and fully airgapped patterns. Decide where the control plane, inference, runtime, and retained evidence belong, and do not infer the answer from the location of the Git server alone.
## Further reading
- [AI code data residency](https://factory.com/articles/ai-code-data-residency)
- [On-prem AI development](https://factory.com/articles/on-prem-ai-development)
- [Private AI package work needs durable context](https://factory.com/articles/private-ai-package-maintenance)
- [Network and deployment docs](https://docs.factory.com/enterprise/network-and-deployment)