July 19, 2026 · 12 min read
AI is turning operators into builders, commercial workflows into software, and multipreneurship into a practical operating model.
# Go-to-Market Is Becoming an Engineering Discipline
AI is turning operators into builders, commercial workflows into software, and multipreneurship into a practical operating model.
I dropped out of college because I wanted to build companies.
Then I started companies and discovered that ambition is not the same thing as leverage.
I could find problems. I could talk to customers. I could sell a vision and get people excited about an idea. But every software business eventually reached the same wall: turning the idea into a reliable product required technical capabilities I did not have.
Some of the businesses failed quickly. Others failed in more sophisticated ways. Eventually, I stopped launching new ideas long enough to study how real technology companies operated from the inside.
That decision brought me into go-to-market roles at Retool and Replit.
It also placed me inside the most important change I have seen in business.
The obvious version of that change is that AI can write code.
The more important version is that millions of people who understand a business problem can now begin turning their knowledge into software.
That will change who builds, what companies buy, how teams operate, and which skills create leverage.
It is also turning go-to-market into an engineering discipline.
When Bolt.new and Lovable appeared in 2024, most of the conversation centered on whether AI-generated applications were good enough to replace professional developers.
They were not. They still are not a universal replacement for professional engineering.
But that was never the most interesting question.
Bolt.new launched in October 2024, and GPT Engineer became Lovable that December. For the first time, a nontechnical operator could describe an application, watch the system create it, test it in a browser, and continue refining it through conversation.
The output was unreliable. The direction was unmistakable.
Software creation was starting to move from syntax toward intent.
The right question was not: Can this replace an engineer?
It was: What happens when the person who understands the business problem can also build the first version of the solution?
That person might be a recruiter who understands why the hiring process keeps breaking. A support leader who knows which tickets waste the team's time. A salesperson who can see why qualified accounts are being missed. A marketer who knows exactly where launch context gets lost.
Historically, those people submitted requests.
Now they can increasingly build systems.
That is a much larger change than faster coding.
I joined Retool because I wanted a live look at how startups build and operate.
Retool had already built a powerful business around a simple reality: companies need far more software than their product-engineering teams can reasonably prioritize.
Every business accumulates internal workflows, approval processes, operational dashboards, customer tools, and strange spreadsheets holding together something important. Much of the work is too specific to buy off the shelf and too far from the core product to earn dedicated engineering resources.
Retool made that long tail of internal software easier to build.
Then AI expanded the idea. Retool began helping teams connect models with their databases, interfaces, APIs, and workflows. Its launch of Retool AI reflected an important lesson: a language model becomes commercially useful when it can access trustworthy context and take controlled action inside the systems where work already happens.
The model is not the product.
The workflow is the product.
The value comes from understanding:
That is where AI moves from an impressive demonstration to business infrastructure.
Somehow, roughly 12 months after joining Retool, I found myself looking at an employment contract from Replit.
It was surreal because Replit was the clearest expression of the technology that had pulled me into tech in the first place.
Amjad Masad and Replit have spent years pursuing a mission I find genuinely incredible: bring the next billion software creators online.
Today, Replit describes its mission as empowering anyone to turn a digital idea into working software, regardless of technical background. It imagines software creation becoming as natural as writing a story. That mission is not abstract to me. I am one of the people it describes.
I did not study computer science. I came from entrepreneurship, sales, and go-to-market. I could recognize customer pain, communicate value, and understand why someone might buy. But I still depended on someone else to turn most of my ideas into software.
Replit is built around the belief that this limitation should not be permanent.
The mission is a bet on the existence of millions of unrealized builders: people with industry knowledge, customer context, taste, and ideas who have historically lacked the technical means to create.
The next billion software creators will not all become traditional software engineers.
Many of them will remain experts in sales, recruiting, healthcare, logistics, finance, education, or operations.
They will simply gain the ability to encode more of what they know into systems.
For the last two decades, go-to-market teams have mostly bought software and adapted their processes around it.
They bought a CRM, a sequencing platform, an enrichment provider, a marketing-automation system, a call recorder, and a collection of dashboards. Revenue Operations connected the stack. Individual contributors moved information between the gaps.
This produced an expensive contradiction: GTM organizations accumulated more tools while employees continued doing enormous amounts of manual coordination.
Account research gets copied into a document. Call notes get pasted into a CRM. Product usage gets checked before a renewal. Marketing rewrites the same launch information for six channels. Sales asks Product the same questions. Customer feedback is summarized, forwarded, and eventually forgotten.
AI makes more of this work programmable.
But the winning approach will not be adding a chatbot to every tool or generating ten times more outbound copy.
The opportunity is to redesign the workflow itself.
An AI-native GTM system has six connected layers:
The system needs an accurate model of the business: products, positioning, customers, competitors, policies, terminology, and sources of truth.
Without context, an agent produces plausible language. With context, it can perform useful work.
The system needs to observe what is happening: product activity, account changes, customer conversations, market events, campaign behavior, support history, and pipeline movement.
Signals replace arbitrary schedules with reasons to act.
The system needs explicit logic for deciding what matters. Which account deserves attention? Which customer is at risk? Which message is relevant? Which action should be recommended, and how confident is the system?
This is where commercial judgment becomes part of the architecture.
The system must be able to do something useful: update a record, prepare research, create a task, draft a recommendation, trigger a workflow, or route an issue.
An answer that never reaches the place where work happens is not automation. It is another tab.
The system needs permissions, approval thresholds, audit history, failure handling, and clear boundaries around what it can do autonomously.
The more valuable the action, the more important this layer becomes.
The system needs feedback from the outcome. Did the seller use the research? Did the customer respond? Was the account correctly prioritized? Did the workflow save time or merely move the work somewhere less visible?
Without a feedback loop, companies automate their assumptions and scale their mistakes.
This is not prompt engineering.
It is commercial systems engineering.
What would this look like inside your GTM motion?
>
Calugaru Labs helps AI and B2B software companies map high-friction commercial workflows and turn the best opportunities into reliable agentic systems.
>
[DM “WORKFLOW” to start an Agentic GTM Workflow Review →](https://www.linkedin.com/in/nikcalugaru)
Most failed AI projects do not fail because the model is unintelligent.
They fail because the workflow was never understood.
The company starts with a tool instead of a business problem. It automates the visible task while ignoring the decision around it. It connects the agent to scattered data without defining which source is authoritative. It measures output volume instead of business impact. Nobody owns the system after the launch demo.
Five mistakes appear repeatedly:
Companies do not need more AI theater.
They need people who can translate strategy into systems and hold those systems accountable to an outcome.
Most companies do not need a six-month AI strategy engagement.
They need to identify one valuable workflow where manual research, disconnected context, repetitive decisions, or broken handoffs are creating a measurable cost.
That is why Calugaru Labs starts with an Agentic GTM Workflow Review.
The review is designed to answer five practical questions:
When there is a strong fit, the review can become an Agentic GTM System Sprint:
Good starting points include account research, lead qualification, product-signal routing, meeting follow-up, CRM hygiene, launch coordination, customer intelligence, and sales enablement.
The output is not an AI roadmap that sits in a deck.
It is a working system with a clear owner, defined boundaries, and evidence that it improves the workflow.
[DM “WORKFLOW” and bring Calugaru Labs one painful GTM process →](https://www.linkedin.com/in/nikcalugaru)
That need is creating a new role.
The GTM Engineer is not simply a Revenue Operations person with an AI subscription. The role also is not a software engineer who occasionally looks at pipeline data.
It is a builder who understands both sides of the translation.
On one side: customer behavior, positioning, sales process, distribution, pipeline, and revenue.
On the other: data models, APIs, automations, agents, permissions, evaluation, and observability.
The role is already becoming visible. Atlassian has described its AI GTM Engineer as a builder-seller who can help code the playbook. Together AI emphasizes turning GTM strategy into automated systems. Seeq focuses on durable, governed workflows rather than scattered AI experiments. Lovable wants GTM systems built from agents, automations, and workflows. The titles vary, but the underlying job is converging.
The common requirement is not mastery of one automation platform.
It is the ability to move through a complete chain:
Business problem → workflow → context → system → adoption → measurable outcome
As models improve, this translation becomes more valuable, not less.
When execution gets cheaper, choosing what to build matters more. When anyone can generate code, understanding the customer and the workflow becomes a competitive advantage. When agents can take action, judgment about authority, risk, and success becomes part of the product.
The bottleneck moves from typing code to designing the right system.
The same shift affects entrepreneurship.
I have never wanted to build only one company. I want to create software, services, media, consumer products, and businesses that may not fit neatly into an existing category.
For years, I treated that instinct as a failure to focus.
Alex Lieberman, the co-founder of Morning Brew, gave it a better name: multipreneurship.
In his essay on building multiple businesses, Alex describes repeatedly focusing on the zero-to-one stage, bringing in an operator, and then returning to create again.
AI makes that model available to a wider group of founders—not by eliminating the need for teams, but by increasing the amount of coordinated work one person can initiate and direct.
A founder can research a market, prototype a product, test positioning, build an internal tool, analyze customer conversations, and create repeatable operating workflows with far fewer initial resources.
The founder's job shifts from performing every task to designing the system in which humans and agents perform the work together.
That is only possible if the system has context, boundaries, feedback, and accountable owners.
Multipreneurship without operating discipline becomes a graveyard of half-built ideas.
Multipreneurship with agentic infrastructure becomes a legitimate company-building model.
Calugaru Labs exists to build at this intersection.
The work spans AI product prototypes, agent workflows, automation systems, and go-to-market infrastructure. But the underlying thesis is consistent:
My background gives me a specific perspective on this work.
Entrepreneurship taught me that building something does not mean anyone wants it. Sales taught me to investigate the real problem behind the request. Retool showed me how much business software remains unbuilt. Replit showed me how dramatically the population of builders can expand.
Calugaru Labs is where those lessons become systems.
It is also how I approach AI solutions for companies: identify one expensive workflow, understand the decisions and context inside it, build the smallest useful system, put the right controls around it, and measure whether it changes the outcome.
That is more valuable than selling a company an abstract AI transformation.
It creates proof.
The next phase of enterprise AI will not be won by the company with the largest collection of AI tools.
It will be won by companies that can turn their unique context into reliable action.
They will know where their sources of truth live. They will redesign workflows instead of decorating them with chatbots. They will give agents enough authority to create leverage without giving them enough authority to create invisible risk. They will measure whether the system improves the business. They will develop people who can move fluently between commercial strategy and technical implementation.
That is the work of the Agentic GTM Engineer.
It is the discipline I am building Calugaru Labs around and the work I want to help lead inside one of the companies pushing AI forward.
The next billion software creators are coming.
Many of them already work in go-to-market.
The smartest companies will not wait for them to call themselves engineers before giving them the tools to build.
Calugaru Labs works best with AI and B2B software teams that already have a real GTM motion—and can point to a workflow that is too manual, fragmented, slow, or dependent on knowledge trapped inside individual people.
This is a strong fit if:
It is probably not a fit if the goal is mass-producing generic outbound, adding a chatbot without a defined use case, or automating a process nobody has taken the time to understand.
If you have one high-value GTM workflow that should become a reliable system, send me the problem. I will tell you whether I believe an agentic approach can improve it and what I would investigate first.
Message me “WORKFLOW” with four things:
[Request an Agentic GTM Workflow Review →](https://www.linkedin.com/in/nikcalugaru)
I'm Nik Calugaru. I combine customer insight, commercial strategy, and agentic engineering to build practical AI systems through Calugaru Labs.
