AI copilots will be built into individual applications, where they can use that application's data, APIs, and workflows.
2
Production copilots combine user experiences, a router, specialized agents, plugins, and observability with guardrails.
3
Teams should start with narrow features, watch user behavior, decompose complicated tasks, and add automated evaluations as the system grows.
Summary
Tristan Zajonc argues that AI copilots will become features inside existing SaaS applications rather than replacing those applications or being controlled by one universal assistant. He describes three product patterns: conversational interfaces, commands embedded in user workflows, and event-driven automations. His proposed production architecture has a front end, a router, specialized agents, plugins for data and external systems, and observability and guardrails. Agents can call functions, connect to deterministic workflows, and delegate to other agents. Zajonc is direct about the main production problem: reliability and performance. He recommends starting with narrow features, observing every user interaction, separating complex domains into smaller agents, and building automated evaluations into CI/CD. Dynamic few-shot examples can improve behavior without fine-tuning. He also suggests treating the front end as an API that agents can manipulate. In the discussion, he says current autonomous systems are still unreliable, while narrow features such as documentation chat and inline bug fixes already work well.
Zajonc expects every application and business domain to gain its own tailored AI copilot. The copilot would connect to the application's internal data and APIs and adapt to the workflows of a marketer, salesperson, doctor, teacher, scientist, or engineer. He does not expect one personal assistant to orchestrate every application. He uses a complicated patient-facing application as an example of software that a general conversational system could not simply replace. The existing application contains domain-specific data and workflows, so the copilot should be embedded inside it and extend what users can do.
Copilots are appearing as chats, commands, and automations
The first interface pattern is conversational chat, which can support knowledge discovery, ad hoc queries, and information retrieval. The second is a command embedded in a specific workflow. Zajonc points to Hex, where natural language can produce SQL, fix errors, and suggest improvements. The third is automation triggered by an event. His GitHub Copilot X example starts work when someone opens a pull request, then looks for bugs, suggests code-review changes, and summarizes the review. These patterns move from helping users find information, to helping with a task, to completing work with limited intervention.
A copilot system needs a shared router and specialized agents
Zajonc describes a production system with three broad layers. The front end provides chat, one-turn commands, or event-driven automation. A common router then sends each request to the internal AI system suited to that domain. A text-to-SQL request could go to one agent, while a support conversation could go to another. Each agent uses a foundation model to respond to language and decide which tools or functions to call. This lets multiple product experiences share an underlying system while keeping domain-specific behavior in separate agents.
Plugins connect agents to data, APIs, and deterministic workflows
The plugin layer gives agents access to systems outside the model. A plugin can search a vector index for context, store information, call a sales service, or invoke an internal workflow with fixed behavior. Zajonc presents OpenAI's function calling as an architecture for letting an agent choose a function and pass it the required information. He also expects recursive systems in which one agent calls another agent with its own limited set of plugins. That creates a hierarchy where different parts of the overall task can be handled by specialized components.
Reliability and performance are the main production problems
Zajonc identifies reliability and performance as the main challenges for production copilots. His first advice is to start with a simple feature, since even a narrow copilot can improve a product. Teams should watch user conversations and actions closely at the beginning, because direct inspection can expose problems quickly. He also recommends isolating complicated areas into narrower workflows or agents. A single agent should not try to do everything, decide everything, and plan every step. Decomposition gives teams more control over some areas while leaving higher-level planning more flexible.
Evaluation and feedback should become part of the development system
As a copilot becomes more sophisticated, Zajonc recommends formal automated evaluations, especially for difficult analytical queries and automations. He says these evaluations should be integrated into CI/CD. For ongoing improvement, teams can collect feedback, identify failures, and dynamically insert relevant few-shot examples into prompts. This avoids creating one very large prompt and avoids the complexity of fine-tuning a model. The examples become a feedback system for the application. He also suggests treating the front end as another plugin API, allowing an agent to alter the interface and create a more dynamic user experience.
Narrow copilot features are more dependable than broad autonomous agents
In the discussion after the talk, Zajonc acknowledges that current autonomous agents do not consistently work. He has more confidence in focused features that improve an existing workflow. Chatting with documentation can be implemented quickly and can be more useful than searching documentation. In Hex, a copilot can fix a narrow execution error, such as a type error or a missing comma, directly in the workflow. He expects richer autonomous systems over the following years, but describes the field as still being in its early stages. He expects software to include conversational access and workflow enhancements as core product features.
"I think we're entering an era where every single application out there within every single vertical domain will be enhanced by its own specialized customized tailored AI co-pilot."02:56
Who should watch
You are adding generative AI to an existing SaaS product and need to decide whether chat, inline commands, or event-driven automation fits the workflow.
Your team is moving from a prototype to production and needs practical guidance on agent boundaries, function calling, evaluations, and user feedback.
You are assessing autonomous agents and want a candid distinction between narrow features that already work and broader systems that remain unreliable.
