Taras Tymoshchuk, the Founder & CEO of Geniusee.
getty
Not long ago, the tech world was obsessed with newly minted, highly lucrative prompt engineers. This was a critically important role at the early stage of LLM development when the output depended heavily on phrasing. Today, the role of the dedicated AI prompter is disappearing just as rapidly as it emerged.
Since LLMs can now automatically rewrite our inputs into clear, effective prompts, the main complexity lies in shifting the levels. We need to know how to build the solution instead of asking the model.
Today, while a prompter interacts directly with the separate query, an architect is a multi-responsible person. They define the issue, select an approach to solving it, design the architecture, address data quality, set up retrieval pipelines, build evaluation frameworks, prevent hallucinations and scale.
In more advanced enterprise AI use cases, multiple specialized agents are increasingly working in tandem. In a mature AI-first company, you might have one agent designed exclusively to process images, another to scrape and synthesize web data, a third to generate code and a fourth to oversee quality control.
The AI architect's job is to act as the general contractor for this digital workforce. They must decompose a complex business problem, identify exactly which specialized agents are required to solve it and design a system that enables these agents to communicate seamlessly and deliver the business value the client actually needs.
The numbers back this up. According to McKinsey's November 2025 State of AI report, 62% of surveyed organizations are already experimenting with AI agents, and nearly a quarter have begun scaling agentic AI within their operations. Furthermore, a June 2025 Gartner, Inc. report identified multiagent systems as a top strategic technology trend and predicted that by 2028, one-third of enterprise software applications will include agentic AI, up from just 1% in 2024.
Let's take an example of customer service. If a company might have deployed a single LLM to act as a chatbot a year ago, then an AI architect would design a multiagent workflow today:
1. Agent A interacts with the customer to qualify a complex refund request.
2. Agent B simultaneously cross-references the CRM and inventory databases to verify the claim.
3. Agent C autonomously processes the payment and updates the ledger.
4. Agent D audits the entire transaction in real time to ensure it complies with company policy and regulatory standards.
AI can generate code and automate prompts, but it still can't decide what exactly should be built to solve your company's unique operational bottlenecks. AI architect candidates should be assessed through concrete signals during the hiring process:
A strong architect will push back on the brief before starting to design. Start with a vague request ("We want to use AI in support"), and see how they reframe it. Clarifying questions relating to business KPIs, current workflows, data availability and the cost of failure can determine the great candidate, while candidates who jump straight to a model or tool choice without first addressing the problem can be a red flag.
Take a real workflow (e.g., a refund process or claims triage system) and ask them to break it into discrete responsibilities. Who retrieves the data? Who reasons over it? Who acts, and who audits? The best candidates do this naturally. Be wary of a candidate who gives you a vague "we'll use an agent for that" without defining what the agent knows, what it produces or what keeps it in bounds.
Can they defend their choices in plain language? Ask about a real decision they made—why RAG over fine-tuning, why one model over another, and what they'd do differently today. Ask them to walk a non-technical stakeholder through that decision. The answer tells you more than any whiteboard exercise. A candidate reaching for the newest framework by default or hiding behind technical complexity when asked to justify a call should be cause for concern.
Security is where I've seen the most expensive mistakes because architects often assume it belongs to someone else. Ask how they've handled user data in past systems, what they'd do if a prompt were injected maliciously and how they'd ensure an audit trail exists. The answers are revealing. The proper candidate won't address compliance as the task for the deployment team instead of the architect's.
Hiring an AI architect isn't a pure engineering decision. The interview loop should include, at minimum:
• A senior engineering leader to assess system-design depth.
• A data or ML lead to validate the approach and evaluation rigor.
• A business owner from the function the architect will serve (ops, support, risk, etc.) to confirm they can translate business problems, not just technical ones.
• A security or compliance representative, especially in regulated industries.
Even the right hire underperforms without the right setup. The most common mistake I see is handing a new architect a broad mandate and expecting results. That doesn't work.
What makes an impact is a defined problem with a measurable outcome, such as reducing refund-handling time by 30% or cutting manual triage by half. Setting up a concrete goal drives solid decisions and produces the value that the business can evaluate.
Beyond the mandate, the architect needs direct access to data, systems and the people who run the workflows they're redesigning. Every layer of bureaucracy between the architect and the problem costs weeks.
Finally, legal, security and compliance need to be brought in at the design stage, not handed a finished system to approve. In my experience, governance delays at the end of a project are almost always the result of governance being ignored at the beginning. When those teams are partners from the start, the reviews become a formality rather than a crisis.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。