For the past few years, most people’s experience of AI has been conversational. You type a question, a model writes an answer, and the exchange ends. That’s useful, but it isn’t the same as handing a system a goal and trusting it to see the job through. A newer class of AI agents is built for that: plan a multi-step task, use tools, check its own progress, and keep going until the work is done. For an industry as software-heavy and data-rich as automotive, the implications are significant.
The idea is gaining traction in agentic ai in automotive discussions because modern vehicles produce more data than engineering teams can review by hand. Earlier special-purpose systems, like the chess engine that beat a world champion in 1997, were brilliant at one narrow job. Today’s tool-using agents can take an ambiguous, open-ended assignment and work out the steps themselves.
What makes a system “agentic?”
A language model on its own receives a prompt and returns a response. An agentic system wraps that model in a loop. It perceives its situation, reasons about what to do, acts, observes the result, updates its memory and repeats until the goal is met. Crucially, the agent isn’t confined to the model’s built-in knowledge. It connects to outside systems, such as databases, ticketing tools and APIs, to gather information and take real actions, and depending on preference it can run with minimal human input.
The building blocks
Most agentic architectures break down into four capabilities:
- Orchestration manages the overall task and delegates pieces of it to sub-agents.
- Perception takes in the assignment and the raw material: emails and service tickets, documents like specifications and PDFs, and structured data such as databases and sensor feeds.
- Reasoning weighs that material, chooses a course of action, and decides when the task is finished.
- Action connects the agent to outside services, often through MCP (Model Context Protocol) servers that publish the tools an agent is allowed to use.
Memory ties these together. Because language models are stateless, the framework has to feed conversation history back to them. Longer-term memory, held in vector databases or other stores, lets an agent draw on past incidents, project histories and domain documents.
Where the car comes in
Think about what an engineer does when an intermittent fault appears during a test drive. They collect logs, compare them against earlier runs, check specifications, form a hypothesis and decide what to test next. Every step is a mix of reading, reasoning and acting across several systems, which is the kind of workflow agents are designed for. Heinlein notes that Sonatus is building multi-agent systems for use cases ranging from pre-production test and validation through after-sales service, so the same logic extends across a vehicle’s lifecycle.
Start simple, then add agents on purpose
It’s tempting to assume more agents mean better results, but the guidance runs the other way. A single agent, with its own reasoning, memory and tools, can handle focused workflows such as an internal documentation assistant or report generation. Multi-agent designs, in which specialists like a “researcher,” “planner,” “executor” and “reviewer” coordinate, make sense for specific needs like specialization, parallel work or verification. The cost is coordination complexity for the orchestrator.
Scope matters too. When a task is too large, the data is unstructured or prompts hit their length limits, models can hallucinate or “forget” key facts. Splitting work into smaller serial or parallel tasks helps. So does limiting the tools each agent sees, because overloading an agent with too many tools or overly complex schemas can lead it to pick the wrong one.
Guardrails are part of the design
Autonomy raises the stakes, particularly in a safety-critical industry. Sound agentic architecture limits agents to approved tools, builds in error handling and managed retries, and enforces guardrails so tool calls follow business logic and security policies. Human oversight remains essential wherever uncertainty, risk or financial exposure is high.
The outlook
The field is moving quickly. As more services publish MCP interfaces, agents gain access to more inputs and more ways to act, and the engineering challenge shifts from “can an agent do this?” to “how do we build it reliably at production scale?” For automotive teams, the answer will come less from any single model than from architecture: how perception, reasoning, memory and action are structured, and how much autonomy each task has earned.
