The agent's-eye view · re-scored
These tools are powerful — that was never the question. The real test is whether an autonomous agent can drive the whole lifecycle to a complete design — validated in simulation and backed by full program management — in a day, with no human prompting each step. Not a flying aircraft overnight; the complete digital design, proven by analysis and managed by a real program plan. Scored hard against that bar: headless, MCP-native, agent-legible, and orchestratable by a structured program of work. Most of the suite is not there yet — and this page is deliberately critical about why.
The bar
Four properties every tool in the chain has to have. Today, almost none have all four — so the score is capped by whichever one is missing.
Everything the GUI can do, available by API or CLI with no screen — and at full parity, not a convenient subset. If a step only exists in a menu, an agent is blocked or reduced to screen-scraping.
The agent discovers and calls capabilities directly — a Model Context Protocol server or equivalent typed interface. Not a REST API you must reverse-engineer; a contract the agent can introspect and invoke.
Where a GUI must remain, it has to be deterministic, stable under automation, discoverable, and machine-readable — predictable DOM, no renderer freezes, affordances an agent can find, errors that state the fix.
The work must plug into a structured program an agent executes — a Work Breakdown Structure of deliverables, criteria and milestones — not a human prompting the agent through every task.
The keystone — and the biggest gap
The single most important missing piece isn't inside any one tool — it's the orchestration layer above them all. Instead of a human prompting and guiding every lifecycle element, the work has to be captured as a structured, executable program:
A program of deliverables that must meet criteria that satisfy accomplishments that deliver to milestones.
That is a Work Breakdown Structure / IMP-IMS — but made executable by agents. Each deliverable is bound to an agent work package with machine-checkable acceptance criteria; criteria satisfaction rolls up to accomplishments; accomplishments burn down to milestones and gates. The human sets the milestones and the criteria; the agents do the work and prove it met the bar. This is the difference between "an agent that does a task when asked" and "a program that builds the whole solution."
Today — the model exists
Teamcenter IPP&E already carries the data model: Program, WBS work packages, OBS, deliverables, criteria, accomplishments, Approval-Gate events, predecessors. The structure to hang this on is real.
Missing — the execution binding
Nothing dispatches a work package to an agent, and nothing auto-verifies a deliverable's criteria. The WBS is authored by hand, through an agent-hostile UI. It describes work; it can't yet run work.
The build we're doing
An agentic WBS: work packages that fire agent tasks, criteria checked programmatically against the live model, status rolling up to the gates automatically. That binding is the highest-leverage change in the entire suite — it's what makes "a day" possible.
The scorecard
Each tool against the four criteria, then an overall agentic-readiness score (0–10) — how close it is to letting an agent deliver through it unattended. Critical by design; engineering power is assumed and not what's being measured.
| Tool | Headless | MCP / agent-API | Agent- legible UX | Orchestr- atable | Score | The critical take |
|---|---|---|---|---|---|---|
| QuestaFPGA verification · EDA | ✓ | ✗ | — | ✓ | 7 | The most agent-ready of the suite. Batch vsim -c + .do scripts are built for CI — no GUI in the loop, self-checking, re-runnable. Our 8 RTL blocks are written to regress in one command. The one gap: no MCP, so an agent still shells out and parses text logs instead of calling a typed interface. |
| TeamcenterSOA / REST backend | ✓ | ✗ | — | ~ | 6 | The headless backend is genuinely strong — we pushed 57 logical items, 51 verifications and 24 standards by script, idempotent and verified by read-back. But you must know the BMIDE types cold, there's no MCP, requirement naming-rules reject valid IDs, and SOA-created items land "homeless" (unsearchable). Powerful, unforgiving, undocumented for agents. |
| Simcenter AmesimSystem simulation | ✓ | ✗ | — | ~ | 5 | The best headless story — ame_apy ran the whole 6-DOF suite unattended and we authored a native submodel — but it fought us: the shipped model wouldn't compile headless until we hand-fixed the linker, and the API is so sparsely documented the run sequence had to be reverse-engineered. Capable, not agent-ready out of the box. |
| CapitalE/E architecture | ~ | ✗we built one | ~ | ~ | 4 | No native headless authoring and no MCP — we had to build an MCP bridge and a bundle→project-XML generator to make it agent-drivable at all. Import and diagram/logic generation still run in the GUI. It proves the model can be authored by an agent; it doesn't ship the means to. |
| NXMechanical | ~ | ✗we built one | ✗ | ✗ | 3 | NX Open batch exists but ships undocumented for an agent's path, so the design work was driven by screen — fiddly numeric fields that need a double-click, MCD-vs-Modeling launch traps, a managed-import dialog that defaults to the wrong item type. We have since built a headless NX MCP (arbitrary NXOpen Python, GUI-less STEP/JT export and shaded renders) that proves NX can run agent-driven — but that is our bridge, not a shipped product (no official MCP; native-parts-only). The score stays here because the product hasn't changed: the capability is real, and Siemens needs to provide it. |
| TeamcenterActive Workspace (web UI) | ✗ | ✗ | ✗ | ~ | 3 | Where an agent must use the web UI — BOM, schedule, WBS, quality — it is the weakest link: the renderer freezes under automation (30 s CDP timeouts), affordances are hidden (WBS child-add creates a second root; the real path is Timeline → Quick Add Plan), errors are cryptic ("no matching Naming Rule" — the answer is "-"), and actions silently no-op. A rich model trapped behind an agent-hostile UI. |
| MADeReliability / PHM | ✗ | ✗ | ~ | ✗ | 2 | The critical case: no headless path at all. The reliability model, FMECA and the report wizard are GUI-only, and export is PDF-only. An agent can click through it, but it cannot script it, feed it, or read its results back as data. For "a solution in a day," a GUI-only analysis tool is a wall. |
| The neutral bridgewhat we had to build | ✓ | ✓ | — | ✓ | 9 | Not a Siemens product — the proof of the pattern. One neutral JSON contract + an MCP that authors, validates and pushes, idempotent and verified by read-back. This is the missing shape every tool above should ship natively. That we had to build it is itself the headline finding. |
Not yet exercised, tracked for later: Xpedition (PCB — EDA, likely scriptable, layout GUI-heavy), Polarion (ALM — REST + webhooks, promising as an MCP-wrappable requirements/verification backbone), and Xcelerator's cloud services APIs.
The harder truth
The four criteria make each tool agent-ready — that's table stakes. None of these ten live inside a tool. They're the connective tissue between and above the tools, and they're where "a day" is actually won or lost. Each is anchored to something that bit us this weekend.
If a human reviews the output, there is no day — the bottleneck moves from building to checking. Evidence: a false "the FPGA is a device in Capital" claim sat live until another session caught it, and the as-analysed-vs-as-designed conflict was fixed by hand. Need machine-checkable criteria on every artifact, automated cross-domain conformance, and provenance you sample instead of re-reviewing.
A day is hundreds of convergence iterations. The only place we iterated freely was headless Amesim (~170 s a run); every GUI gave us ~3 passes. Tools have to be fast enough to sit inside an optimization / design-space-exploration loop — headless isn't enough if a single run takes an hour.
A day means many agents at once — and we proved it's unsolved: two sessions clobbered nav.js and coordinated by hand-passed messages. The PLM has to be a real concurrent source of truth (locking, merge, transactions); today it's brittle under a single automated session, never mind forty.
"One neutral contract" is too shallow. A "component" means different things in Capital, TC and NX — without a shared ontology and federated identity, agents burn the day mapping meanings. The "homeless items" and the two near-identical TC servers we conflated are the identity gap. And a day needs round-trip diff/merge, not one-way push.
Design starts from what the human wants; garbage-in wastes the whole day. We reverse-engineered an RFP into a spec by hand. Agent-assisted requirement elicitation and automated validation — is the spec complete, consistent, verifiable? — gates everything downstream.
A day is impossible from scratch. It needs a machine-queryable library of reference designs, verified sub-systems and part/standards catalogs. The tools have fragments (Capital libraries, TC Classification, the standards we materialized) but they're not agent-composable — so every project pays full price.
Hidden non-deterministic state — auto-IDs, timestamps, layout, session state — means the same intent yields a different result. You can't audit, diff, or certify that. Reproducible builds are non-negotiable for anything regulated, and a debugging necessity when an agent build goes wrong.
"No human prompting each step" ≠ "no human." The human moves to objectives, criteria, gates and trade-offs — and accountable sign-off. Design where those decisions live and make them fast approvals, not re-reviews of everything. Too many touches kills the day; too few makes it unaccountable and unsafe.
You can't improve what you don't instrument — and we have zero pipeline telemetry. The scorecard is qualitative; the quantitative version is a time-to-solution dashboard. It's its own thread — expanded just below.
Agents compress the design / engineering / PLM loop — not fab, procurement or flight test. The move is to virtualize more (SITL, digital twins, virtual qualification) so the physical dependency shrinks and moves later. "A full digital system, verified in simulation, in a day" is honest and huge; "a flying aircraft in a day" is not — and claiming it would burn trust.
This is what turns "we think we're getting faster" into "cycle time fell from X to Y, and the seam cost is now the top blocker." It is how this whole scorecard stops being an opinion — so we built the v0.1: the Time-to-Solution Dashboard →, with a spec, an event schema, a stdlib aggregator, and this build reconstructed as the baseline to beat.
What must change
Not polish — structural. Ranked by how hard they block an autonomous, end-to-end build.
| Change | Where | Why it's a blocker |
|---|---|---|
| An executable agentic program layer — bind WBS deliverables to agent work packages with machine-checkable criteria that auto-roll-up to accomplishments and milestones | Teamcenter IPP&E (+ an orchestration service) | This is the keystone. Without it a human still sequences every step, so nothing else buys you "a day." The data model exists; the execution binding does not. |
| Headless-complete APIs at full GUI parity for every tool — especially the ones that have no API today | MADe (none), NX authoring, Capital authoring, AW authoring | An agent cannot drive what only exists in a menu. A GUI-only step anywhere in the chain caps the whole pipeline. |
| Ship an MCP (or equivalent typed, introspectable interface) per tool | Every tool — today zero ship one | Agents should discover and call capabilities, not reverse-engineer REST and parse text logs. We had to build the one MCP that exists in this thread. |
| Automated cross-domain verification + a tamper-evident provenance chain — machine-checked criteria on every artifact, not human review | Cross-suite (the digital thread) | At agent speed the bottleneck is checking, not building. If a human must review the output there is no day — and a false claim can sit live (it did) until someone notices. |
| A concurrent, transactional source of truth — locking, merge and conflict resolution for many agents on one model | Teamcenter / the PLM backbone | A day means massive parallelism. We clobbered our own nav.js with just two sessions; the PLM is brittle under one automated session, never mind a fleet. |
| Change | Where | Why it matters |
|---|---|---|
| Agent-legible UX for the GUIs that remain: deterministic DOM, stable under automation, discoverable affordances, machine-readable errors that state the accepted value | Teamcenter AW (renderer freezes, hidden WBS-add, "-" naming rule, silent no-ops) | Even with APIs, some steps will be UI-driven for a while. Today those steps are the fragile part of every run. |
| One neutral, validated interchange contract between tools — standardize the bundle we prototyped so tools interoperate without lossy, hand-mapped handoffs | Cross-suite (the N² seam problem) | Most of the "day" is lost at the seams. A single validated contract turns N² translators into N adapters. |
| Idempotent, transactional, verifiable operations everywhere — safe re-runs, read-back verification, rollback on failure | All authoring paths (GUI ops mostly aren't) | Agents must be able to retry and prove success. Our SOA push is idempotent; almost nothing GUI-driven is. |
| Pipeline telemetry — a time-to-solution dashboard (cycle time per domain, human-touch count, iterations, rework rate, seam cost) | The orchestration layer | "Get better quickly" is impossible without measuring. Today the assessment is qualitative; this is the quantitative version, and it names the real blocker instead of guessing. |
| An agent-queryable reuse library — reference designs, verified sub-systems, part and standards catalogs, composable by an agent | Cross-suite (Capital libs, TC Classification, standards) | A day from scratch is impossible. Reuse is what makes "any solution" tractable; the fragments exist but aren't machine-composable. |
| Change | Where | Why it matters |
|---|---|---|
| Documentation written for agents — machine-readable capability specs, working examples, the accepted patterns | Amesim (ame_apy), TC BMIDE types, NX Open | We reverse-engineered the run sequence, the type names and the WBS path. Every hour of that is an hour not spent building. |
| Direct machine-readable exports — data and images, not PDF-only | MADe reports/diagrams, TC structure views | PDF-only forces screen-capture; an agent needs the numbers and the picture as data it can reuse and verify. |
| Reproducible, deterministic builds — same intent → same result; no hidden non-deterministic state | All authoring (auto-IDs, timestamps, layout) | You can't audit, diff, or certify a build that isn't reproducible — and you can't debug an agent run that doesn't repeat. |
Assessment log