The journey to a venture builder assistant

What is the journey to a Venture Builder Assistant?

The journey to a Venture Builder Assistant is the path from a heavy custom plan to a small Agentic Assistant, built in replaceable blocks on the ecosystem an organisation already runs. The result today is an assistant where orchestrated agents share the work. At La Plage Factory it took two platform changes, and the questions, the program content and the human review stayed in place through both.

You may believe an Agentic Assistant needs a full tech team. When I started, that was true. The tools have moved since then, and the decision that matters has moved with them. Over nine months, that movement unlocked a lot of potential and sped up how fast an assistant can be integrated with the tools a team already uses. A lot is still unknown. The cost of building has dropped. The cost of choosing the wrong foundation has not.

This article walks through the decisions in order, with the platforms, the timing and the friction I met along the way. If you lead an SME or a business unit and have an assistant project sitting on a list, you will find a sequence you can reuse.

Each section covers one decision. Each section has a short explanation of the terms and a short account of what I did. Use the explanation to learn the term. Use the account to see the choice and its cost.

Why an agentic assistant no longer starts with a tech team

An Agentic Assistant takes a question, pulls the right material and proposes an answer. In its more advanced form, it uses orchestrated agents. Several specialised agents each do a narrow task, and an orchestration layer coordinates them. This is the form I run today. The assistant proposes. A person decides what to do with the proposal.

The assistant has three parts. The first part is the question from the user. The second part is the material that the assistant finds. The third part is the proposed answer. A person reads the answer and decides what to do.

When I started, delivering that meant custom code, a set of agents, connectors to each data source and a full RAG setup. RAG stands for retrieval-augmented generation: the assistant retrieves passages from your own content before it writes an answer. Retrieval-augmented search of that kind needed engineers to build it and keep it running.

A connector is a link between the assistant and a data source. Each data source needs its own connector. A connector stops working when the data source changes. Then an engineer must repair it.

Frontier vendors have since added connectors natively, strengthened MCP (the Model Context Protocol, a standard way to connect assistants to tools and data) and shipped agentic features such as Claude Cowork. Pieces that used to be project work are now settings and licences. A small group can reach a working first version: a person who knows the content, a person who can configure the platform and a handful of pilot users.

That does not remove the need for skill. Someone still has to define the questions, curate the content and test with real users. What disappears is the assumption that all of this waits in an engineering queue.

The real risk is a build locked into a stack that shifts every week

When you build custom, you own the connectors, the retrieval layer and the agent logic. Each one is work you maintain. When vendors ship the same capability natively, you have two options. You redo your work on the native version, or you throw yours away. Either way, the time already spent has no resale value.

That is why I held back from a heavy custom build on this project. Frontier vendors were adding connectors, stronger MCP and agentic features, and the direction was visible. Deciding what to leave out kept the project easy to move. A component you did not build cannot become a migration.

A migration is the work to move from one component to another. It needs a new configuration. It needs a new round of tests. It stops other work for the time it takes. A small project feels this cost more than a large one, because the same people do both jobs.

Here is a check I now run before any build. For each component, ask whether a frontier vendor is likely to ship it within the next two quarters. If the answer is yes, rent it or wait. Build only what is specific to your organisation. In this case, that was the questions, the program content and the review loop with people.

What La Plage Factory needed from the assistant

La Plage Factory runs an incubation program for startups. Founders and mentors needed answers grounded in that program and tied to each startup’s context and its progress in Vianeo Business Design, the business design method the startups work through.

The same question can call for a different answer depending on where the startup stands in that work. A founder asking how to test a customer segment needs one answer early on and another once evidence has come in. A generic chatbot cannot know the difference. The assistant needed the program content, the startup’s context and the stage of work, all at once.

The assistant uses three inputs. Input one is the program content. Input two is the context of the startup. Input three is the stage of work. If one input is missing, the answer is less useful to the founder.

That requirement is where semantic authority comes from. An answer carries weight when it is grounded in what the program has distilled and shaped by the startup’s own position. I also set a standard for how answers read. They had to be straight to the point and written in a CEO voice: short, specific, something a founder can act on the same day.

Before choosing any tool, I wrote down the questions founders and mentors actually ask. That list became the test set for every version that followed. Each new version had to answer the same list. This gave me one fixed way to compare versions.

What to leave out of a first version

The original plan was custom code, a set of agents and a full RAG setup. Looking back, four things stayed out of the build because a vendor was likely to cover them:

• Custom connectors to the organisation’s documents and tools.
• A self-built retrieval layer.
• A self-built agent framework.
• Anything that depended on one specific model.

Each item on this list has the same risk. A vendor can ship it. Then your own version is a duplicate that you must maintain.

Leaving these out made the first version smaller and made every later change cheaper. The effort went into the questions and the content, which no vendor can supply.

Choosing Microsoft Copilot for an Agentic Assistant

Four months ago I chose Microsoft Copilot, since La Plage already runs on Microsoft. Accounts, identity, documents and permissions already live there. The model is one part of the system. The ecosystem around the model carries more weight: what it connects to, who is already signed in and what the organisation has already approved. Integration with what the organisation already uses matters more than the model on its own.

Identity means that the system knows who the user is. Permissions mean that the system knows what the user can read. The assistant must respect both. When the assistant uses the Microsoft setup that already exists, the organisation does not need to build these controls again.

For most SME and business unit leaders the same logic applies. Pick the platform your people already open every morning. Adoption friction is lower, and security questions have shorter answers. A technically stronger option outside your ecosystem usually costs more in change management than it returns in quality.

Building an Agentic Assistant in blocks

I built in blocks, and each block was tested with real users before the next one was added. The order was:

1. One agent, answering the real question list from the program content.
2. Azure, to handle token payment for usage.
3. Power Automate, to connect the assistant to the workflows around it.

A token is a small unit of text. The model reads tokens and writes tokens. The vendor charges for each token that the model uses. Azure handles this payment, so the cost of use is visible and controlled.

A workflow is a series of steps that a tool does in a fixed order. Power Automate links the assistant to the workflows that already exist around it. The assistant then fits into the daily work of the team.

Testing between blocks gives a clean signal. If something breaks or confuses people, you know which block caused it. I also watch weighted engagement. A handful of founders and mentors who return every week tell me more than a launch day full of curious first clicks. The people who come back are the ones whose questions improve the next iteration.

The switch to the GitHub Copilot harness and orchestrated agents

Three months ago I switched to the GitHub Copilot harness, still in beta. This switch brought orchestrated agents into the assistant. It is the most important part of the result I have implemented. Azure and Power Automate kept changing. It took about six calls to Microsoft support, because the documentation was missing or behind. That is the price of building on a platform that moves.

Orchestrated agents means that several agents work on one request. Each agent has one narrow task. An orchestration layer sets the order, passes the output of one agent to the next and returns one proposed answer. A person still decides what to do with that answer.

A single agent must hold the whole job. With orchestrated agents, each agent can be tested, changed or replaced on its own. This fits the block approach. Each agent is a block. The assistant can grow one agent at a time, and the answers reach the founder with the work shared between agents.

A harness is the layer that runs the agents. It gives the agents their tools and their rules. Beta means that the vendor can still change the product. Plan for those changes before you start.

Today you can even choose the model of your liking within Copilot agents. That option was not there when I started, and it shows why a model-first decision would have aged quickly.

The cost stayed manageable because each block was small. The switch meant rebuilding one layer, the one closest to the platform. The questions, the program content and the human review stayed in place. The assets that carry value sat outside the layer that changed.

Keeping humans deciding on every answer

The assistant proposes answers. Founders and mentors choose. A mentor reads a proposed answer, adjusts it to what they know about the founder and sends it on. What the program distils from those exchanges feeds the next iteration of the content. The loop improves the assistant without handing it the decision.

The loop has five steps:

1. The founder asks a question.
2. The assistant proposes an answer.
3. The mentor reads the answer and changes it if needed.
4. The mentor sends the answer to the founder.
5. The program distils the exchange and updates the content.

This is also a practical safeguard. An answer about a startup’s strategy has consequences. The person who knows the context should own it. The assistant changes how the work is done. The mentor’s role stays what it was.

Three rules that hold today

1. Start with the questions people ask. The questions come first and the tooling second.
2. Pick an ecosystem and build in blocks. One agent first, then the layers around it, until orchestrated agents share the work.
3. Keep the humans deciding. The assistant proposes, people choose, and what the program distils feeds the next round.

In nine months the tools unlocked a lot of potential and made integration much faster. Orchestrated agents are the part of the result that I would point to first. A lot is still unknown, including which layer will move next. Start on the latest tools and expect to iterate. Choose the option that fits your ecosystem today, and keep each block small enough to replace when the platform moves again.

Where to start on your own list

Look at your project list and find the item that has been waiting for engineering capacity. It might be an assistant for sales playbooks, onboarding or internal policy questions. Write down the twenty questions people ask most. Check which ecosystem your people already use. Build one agent there, test it with five real users and decide after two weeks whether to add the next block.

At the end of the two weeks, answer these questions:

1. Do the five users come back without a reminder?
2. Do the reviewers change many of the proposed answers?
3. Which block does the team need next?

If the answers are clear, add the next block. If they are not clear, fix the content or the questions first.

One caution from experience. An assistant amplifies the process underneath it. If the process is broken, the assistant speeds up the breakdown. Start from the pain, fix the process, then add the tool.

Which project on your list is waiting for a tech team it may no longer need?

FAQ

What is an agentic assistant?

An Agentic Assistant is software that takes a question, retrieves the relevant material and proposes an answer. In its advanced form it uses orchestrated agents: several specialised agents, coordinated to work on one request. It recommends and a person decides. At La Plage Factory it answers founders and mentors using the incubation program and each startup’s progress in Vianeo Business Design.

What are orchestrated agents?

Orchestrated agents are several agents that work on one request. Each agent has one narrow task. An orchestration layer sets the order and returns one proposed answer. In the La Plage Factory assistant they came with the switch to the GitHub Copilot harness, and each agent can be tested or replaced on its own.

Do I need a tech team to build an agentic assistant?

Not for a first version. Vendors now ship connectors, MCP support and agentic features natively, so one person with the right access can configure a working agent. You still need someone who defines the questions, curates the content and tests with real users.

Why choose Microsoft Copilot for an agentic assistant?

In this project the reason was the ecosystem. La Plage already runs on Microsoft, so identity, documents and permissions were in place. Integration with what the organisation already uses carries more weight than the model alone.

How do I avoid lock-in when building an agentic assistant?

Build in small blocks and leave out anything a vendor is likely to ship soon. Keep the questions, the content and the human review outside the platform layer. When La Plage moved to the GitHub Copilot harness, only one layer had to be rebuilt.

Who makes the final decision, the assistant or the people?

The people. The assistant proposes answers and founders and mentors choose what to act on. What the program distils from those choices feeds the next iteration.