Coding agents are already inside engineering work. They draft code, review pull requests, debug failures, and turn rough intent into implementation plans.
The hard part is no longer whether an agent can produce code. The hard part is whether a team can explain what context the agent used, which checks applied, where human judgment entered, and what evidence came back with the change.
This article records the engineering profile that preceded the autonomy-first IAS reset. That profile explored a control plane for coding agents in regulated enterprises. It remains historical evidence, not the current product, supported workflow, or offer.
The problem
Most teams begin with an individual workflow: an engineer prompts an agent, the agent changes code, the engineer reviews the diff. That can work for a task. It breaks down when the organization needs the work to be reviewable across teams.
The failure pattern is specific:
- Context is recreated every time. Standards, decisions, domain rules, and prior exceptions sit in tickets, docs, chats, and individual memory.
- Policy is added after the fact. Reviewers see a diff, but not always the context pack, approval boundary, or validator set that shaped the run.
- Evidence is scattered. Commit SHAs, check results, decision requests, and risk notes exist, but they are not attached to one run record.
- Human judgment arrives late. Product and risk decisions appear as Slack interruptions instead of structured requests that the run can resume from.
What IAS does
The earlier IAS profile wrapped coding agents in a governed run path.
| Stage | What IAS makes visible | Why it matters |
|---|---|---|
| Before the run | The intent, context pack, harness profile, validators, and approval boundaries | Reviewers can see what will guide the agent before it touches code. |
| During the run | Job state, blocker reason, decision requests, and policy gates | The run can pause for human judgment without disappearing into chat. |
| After the run | Commits, changed files, check results, risk notes, and review status | The change arrives with a record of what happened and why. |
Three product layers shaped that historical profile:
-
Agent Framework. Local agents run against your Git checkout, work in branches, submit pull requests, and follow your existing review workflow.
-
IAS Hub. The web control plane shows run state, decision requests, evidence, and team-level visibility without becoming the place where source code executes.
-
Context Lake. Reusable context packs collect the standards, rules, decisions, and domain knowledge a run needs, so each agent does not start from a blank prompt.
Who it's for
The engineering profile was designed around three audiences:
AI engineers who want the mechanics: local runtime, context packs, validators, approval gates, and Git-native evidence.
Product managers who need the work to stay steerable: intent quality, blocking questions, run status, and a clear record of what shipped.
Decision makers who are accountable for AI-written code across many repos, teams, and tools. They need one view of the controls and evidence, not another tool-specific dashboard.
What's next
You can inspect the historical docs or the preserved tour for that earlier mechanism work. The current IAS direction starts from a real problem and does not treat this archived profile as a supported product or purchase path.