IN Brief:
- CANoe 20 SP2 introduces MCP-based access that allows AI agents to operate directly against development and test functions.
- Agents can generate CAPL tests from requirements, execute them, analyse failures, repair code, and rerun validation.
- Customers retain their chosen LLM endpoint while Vector provides the agents, skills, MCP tools, and documentation-grounded RAG layer.
Vector has added an agent-based AI layer to CANoe that can operate development and test functions directly from natural-language instructions, extending AI assistance beyond code suggestions into executable engineering workflows. The CANoe MCP Server is available with CANoe 20 SP2, while the associated AI Package provides the agents, skills, and tool definitions needed to connect an external language model to the environment.
Vector’s reference workflow starts with a requirement rather than existing test code. An agent converts that requirement into a CAPL test, executes it in CANoe, analyses failures, repairs the generated code, and runs the test again before presenting the resulting scenario to the engineer for review. CANoe windows are synchronised to the relevant results so the final approval remains with the user rather than the model.
That execution loop makes the development more substantial than adding a chatbot beside an automotive engineering tool. Generative models can already propose CAPL, C#, Python, or other code, but the engineer normally has to move that output into the target application, compile or execute it, retrieve the resulting diagnostics, return those errors to the model, and decide whether another iteration is needed.
MCP gives the agent a structured route into CANoe functions instead. Vector’s tooling can expose configuration analysis, simulation control, communication monitoring, test generation, and coding operations through defined tools, allowing an agent to assemble several actions into one workflow rather than returning text for a developer to implement manually.
The language-model layer remains separate from Vector’s software. Customers can use the endpoint behind tools such as GitHub Copilot or Claude, or connect an in-house model, while Vector supplies the CANoe-specific agentic ecosystem. That separation is relevant for electronics development teams whose rules around proprietary ECU designs, vehicle networks, cybersecurity functions, or unreleased software may dictate where model inference is allowed to run.
Vector has also added a retrieval-augmented generation component based on its own knowledge base and documentation. The RAG layer supplies product-specific information to the agents when they decide how to operate CANoe, reducing dependence on whatever the underlying language model happens to know about a specialist engineering tool from its general training data.
Grounding does not turn generated code into verified code, and that distinction is particularly important in automotive test. A CAPL script can compile successfully while testing the wrong state, message, ECU, timing condition, or diagnostic sequence. Network databases, simulation nodes, test configurations, firmware versions, and project-specific assumptions provide context that cannot safely be inferred from a short natural-language requirement alone.
Vector is therefore keeping the workflow visible. Users can see which MCP tools an agent invokes, which skills it uses, and what it changes in CANoe or the connected development environment. The degree of autonomy can range from asking a question through to delegating a multi-step workflow, with the engineer deciding how far the agent is allowed to proceed.
That transparency will become increasingly important if agentic systems are used in formal verification programmes. Automotive and embedded development environments often have to preserve traceability between requirements, test cases, software baselines, test configurations, results, and defects. Reducing the manual effort needed to construct and rerun a test is useful, but an automated workflow still has to leave enough evidence to establish exactly what was tested and what the agent changed between runs.
The same issue applies to generated repairs. An agent capable of fixing CAPL after a failed execution can remove simple syntax, API, or configuration errors rapidly, yet a passing test does not prove that the final script preserves the intent of the original requirement. Human review remains necessary where the test itself becomes part of the evidence used to release safety-related or otherwise critical electronics.
Vector’s open architecture also gives engineering teams a route to add their own agents, skills, MCP tools, and contextual information. That could allow a CANoe workflow to interact with company-specific requirements systems, coding conventions, simulation infrastructure, or test libraries, although each additional integration increases the need to control tool permissions and establish which actions an agent can perform without approval.
The CANoe AI Package is available as a downloadable extension, with the MCP Server available in CANoe 20 SP2. The most useful measure will not be how much CAPL an LLM can generate, but whether teams can automate repetitive development loops without weakening traceability or test intent. CANoe now gives the model a route to act inside the engineering environment; the remaining discipline lies in deciding where that autonomy should stop.
