What Happens When One Operator Owns AI Across the Business
By Darin LaFramboise UC Davis 07
Prepared for the UC Davis Graduate School of Management & Master of Science in Business Analytics (MSBA) Publications, Sept. 2026
One of the first problems I took on at Kintsugi was an AI support agent that people had learned to ignore. This single task ballooned into a reinvention in how we plan, build, market and sell with AI at the center of our operations, not around it.
The agent was supposed to help engineers answer internal questions and investigate problems. It was getting the answer or recommended next step right about 44% of the time. Even when it was right, someone was required for a full investigation because the trust in the agent was low. Engineers lost focus, questions waited and the company supported a system that had not earned enough trust to save anyone meaningful time.
We already had AI, but we needed someone accountable for making it work within the business. That is where my role came in. At Kintsugi, a sales tax technology company, I act as the AI chief of staff. I manage operations connecting product planning, engineering execution, analytics, go-to-market work and support. Historically, much of that coordination would have involved hiring program managers, project managers, coordinators and analysts. Today, I manage more than 100 AI agents that take on parts of those responsibilities. This lets us focus investments on areas where people add the most value.
The founders created my role around a hypothesis: what would happen if one person had a company-wide mandate to connect our AI efforts, improve how they operated and keep finding the next constraint? In R&D, headcount has grown modestly while output has multiplied. Getting there has required sustained work on the decisions, information and handoffs that determine whether AI is useful.
Give someone responsibility for the connections
My background spans analytics, product management, operations and nearly 20 years in notable tech companies during their hyper-growth periods. I view a company through the flow of work among people. Where does someone wait? Where do they repeat an investigation? Where does a good idea lose context moving from a customer conversation into a product requirement?
I enjoy working in startups because there is a limited window to build, prove market fit and grow into a viable business. As an operator, AI gives me more capacity to remove the delays along that path. Separate teams can improve their own tasks while leaving the connections between them untouched. Engineering moves faster, product planning struggles to keep up and marketing receives more completed work than it can introduce to customers. My mandate extends across those boundaries: working with teams to change workflows, connect systems, develop training and improve the agents supporting them. The objective is to maximize the value of people’s experience by reducing the administrative work that takes them away from it.
In our company, that responsibility sits with one operator. A larger organization may need a team. What matters is that someone owns how the pieces work together and has the mandate to improve them.
Start where reliability changes behavior
I started with our highest-volume internal engineering help channel. Its on-call rotation created a bottleneck: investigating routine questions repeatedly interrupted people responsible for building the product. I studied the requests and responses, then replaced the model, underlying engine and logic guiding the agent’s investigations. Once effectiveness passed roughly 70%, I applied those lessons to other high-volume support channels.
Over time, I brought the agents’ underlying logic into a shared foundation. They gained awareness of related agents’ capabilities, allowing a question to benefit from expertise beyond the first agent receiving it. That moved effectiveness toward 80%. Controlled access to deeper, relevant data improved performance further. Our internal support agents now independently generate answers or recommended next steps that our evaluations find correct roughly 90% of the time. Responses that previously required an average of about two hours of human reading, investigation and interpretation can arrive in under ten minutes.
These are measures of a defined support task. Some requests still require a person to act, and some need further investigation. Deploying an agent does not automatically remove work. If people have to repeat everything it does, the workload remains. Improving reliability enough for people to use the result is where the value begins.
Redesign the work around the new capability
Engineering acceleration exposed the next constraint: how we prepared and coordinated work.
We invest heavily in shared instructions, reusable agent capabilities and automated checks across engineering. Those foundations help generated code follow a consistent structure, making it easier for engineers to review and deploy.
As these capabilities improve, we must continuously update our development process. We call it Hyper Agile.
We moved away from sprint planning toward a continuously prioritized backlog. Engineers pick up work when it is ready, trusting that its priority and requirements have been prepared. Product managers remain responsible for determining which problems deserve investment. Engineers complete technical decisions and retain responsibility for human code review. For this to work, the product requirement document has become one of the most important parts of the company. It still explains the problem, proposed solution, expected value and user stories. But we now write it knowing that agents across engineering, sales, marketing and planning will use it. Ambiguous language can travel much further when multiple agents act on the same document.
One agent evaluates requirements for those different audiences. It runs scenarios against the document and helps identify what is missing before development begins. Product managers prepare product and technical specification drafts asynchronously, with engineers completing the technical detail and catching nuances that require deeper knowledge of the codebase. Product managers and engineers spend less meeting time translating specifications and more time discussing where their product area should go. Engineers have more uninterrupted time to build and explore techniques. Our Friday demos increasingly emphasize how someone built something, giving the team methods they can reuse.
Across engineering, we have measured approximately ninefold (9x) growth year over year in merged code changes per engineer, weighted by complexity. That includes work generated by engineers and agents proactively making improvements and fixing bugs. It measures throughput. Work that previously took months can now move through development in less than a week, with some requests completed the same day. Those gains reflect better models alongside sustained investment in how we specify, build and review work. The instructions, agent capabilities and automated review processes we develop are increasingly part of our intellectual property.
Help people keep up with what AI makes possible
Faster engineering puts more pressure on product managers to have the next valuable piece of work ready.
Our agents synthesize information from sales conversations, support interactions, engineering discussions and roadmap meetings. They suggest customer needs, integrations, usability improvements and architectural work. Much of this happens autonomously overnight, so product managers start the day with recommendations and draft requirements to evaluate. A product manager can consider evidence from far more conversations than they could personally attend or review. Their responsibility is still to determine which problems matter and what deserves investment.
This also frees customer-facing teams from some of the meetings and processes previously needed to relay feedback to R&D. They gain time with customers while product managers gain access to a broader range of customer conversations. The same pattern extends into product marketing. Agents review shipped features and prepare release notes, sales materials, help content and potential customer audiences. Marketing increasingly edits, validates and decides how to use that material.
At Kintsugi, I started with a support agent people did not trust. Today, we can build faster than our customers can absorb the changes. Getting from one constraint to the other requires someone responsible for connecting the work across the business and improving it continuously and centrally without organizational bias. That is the case for giving AI an operating owner. As execution gets faster, the decisions about what to build, where to invest and when to move become more consequential. That is where I want our people spending their time.
About the Author
Darin LaFramboise is AI chief of staff at Kintsugi, where he leads the company’s adoption and deployment of AI in service of a simpler, more proactive approach to sales-tax compliance for growing businesses. He is also co-founder and head of product at Opus Guard, an Atlassian Ventures-backed startup redefining information governance for the AI era. Previously, he led product and ecosystem strategy at Atlassian and Okta, including scaling the Auth0 platform’s throughput sixfold and helping grow the Atlassian Marketplace from $100 million to $1 billion in annual gross sales. He was part of the mobile pivot at Facebook, driving growth across its Ads Platform and Graph Search products. He started his career at ProFlowers in San Diego after graduating from UC Davis. Darin holds a B.A. in economics from the University of California, Davis.