
Shape · Third stage of your AI journey
Design & build sprint
A convincing demo is not the same as an agent people rely on. In this sprint we take one AI use case that your organisation has already decided to back, design it with you, and build it with you, so that you end with a working agent in your own environment and a team that knows how to build the next one.
A demo is not an agent you rely on
By the time a use case reaches this point, the hard organisational work is usually done. Somebody has described the problem, an owner has put their name against it, and the organisation has agreed to commit people and budget. What remains looks like the easy part, and it is where many initiatives quietly lose momentum.
A prototype that works on a laptop is a long way from an agent that works on your data, inside your systems, with the access and security your organisation requires. The distance between the two is mostly design: how the agent connects to what it needs, what it is allowed to do, how people will actually use it, and how you will know it is behaving. Skipping that design is how a good demo turns into a pilot that never ships.
There is a second problem that is easy to miss. If an outside team builds the agent and hands it over, you own an agent, but you do not own the knowledge of how it was made. The next use case then starts from zero, with the same supplier. We would rather you were able to build the next one yourselves.
One use case, designed and built with your team
Design & build is one of our Shape engagements. It is individually scoped, because every use case is different, and it is built around a single, well-defined use case rather than a collection of them.
The starting point is a use case that has been proposed, has a clear description and scope, has a named owner, and has the backing of your organisation to commit people and time to it. If you have worked through Use case prioritisation with us, the one-page brief for a shortlisted use case is exactly the right input.
We then work in three phases, one after the other. First we design the agent with you: how it works, what it connects to, how people will use it, and how it is kept secure. After a design review, we build it with you, in short cycles, with regular demonstrations to the person who owns the use case. Finally we hand it over. The output is a functioning agent, running in your own environment.
We usually draw on our library of reusable building blocks where they fit your business, rather than starting from scratch. Formal release and approval processes, such as a review board, stay with you, and we help you prepare for them.
The scope, the timeline and the price are all set for your use case. There is no fixed length, because a single agent over one document store and a workflow across several core systems are very different pieces of work.
Three phases, after a short shaping step
Shaping (before the work starts)
A short working session to check the use case is ready, scope the integrations and the data work, and agree who is involved on both sides. We compare the use case against the one-page brief, confirm who the owner is, and identify early which people will have a say before the agent can go live, typically security, architecture and the data owners. We also agree the environment, the access we will need, and which cloud and model services the agent will use.
The agent runs on your approved cloud, whether that is AWS, Azure or GCP. We tend to favour the LangChain ecosystem for building agents.
Phase one: Design
We design the agent before we build it. That covers the overall architecture, the data and systems it will connect to, how people will use it, and a baseline security setup. The agent gets its own identity with only the access it needs, so further controls and guardrails can be added later without rework. We agree a small, focused set of tests with the owner, so that everyone knows what “working” means, and we choose which building blocks we will reuse. The phase ends with a design review with your owner and the stakeholders who will approve the go-live.
Phase two: Build
We build in short cycles, with a demonstration to the owner every week so that surprises happen early. We work inside your environment, and where your engineers can join us, they build alongside ours. We run the agreed tests, and people from the team that will use the agent try it and tell us what is wrong with it.
Phase three: Hand over
We finish with a final demonstration, a handover session for your team, and the documents they need to run and extend the agent. For two weeks afterwards we provide light-touch support while your team settles in.
Questions we get asked
How long does it take?
It depends on the use case, so we do not quote a standard length. The scope, the timeline and the price are all set once we have seen the use case. The things that move it most are the number of systems the agent has to connect to, the state of the data, and the number of people who have to approve it before go-live.
Do you need access to our data?
Yes. An agent that works on your data has to be designed and built against it, so we need access to the data and to the people who know it. We work inside your own environment, under your access controls, rather than taking data elsewhere.
Do our engineers have to be involved?
Not required, but strongly recommended. The point of this sprint is that your team ends up able to build the next agent, and the most reliable way to get there is for your engineers to build alongside ours. The one person we do require is the business owner of the use case.
What if our use case is too big?
Then we will say so early. Most use cases fit the sprint format. A very complex one, such as a large system of cooperating agents, needs a bespoke engagement. Training your own models is out of scope in either case.
Which platforms and frameworks do you use?
We build on your approved cloud, whether that is AWS, Azure or GCP, using the model services you are able to use. We tend to favour the LangChain ecosystem, and we draw on our library of reusable building blocks where they fit.
Will the agent be ready for production?
You will have a working agent in your own environment, built with a baseline security setup and a minimal set of tests, designed so that further controls can be added. Your formal release and approval processes, such as a review board, stay with you, and we help you prepare for them.
Who owns what we build?
You do. The code, the infrastructure definitions and the documents are yours. We keep the generic building blocks we bring with us.
What happens after the sprint?
We provide two weeks of light-touch support while your team settles in. Longer-term support is a separate agreement.
How is this different from hiring a software firm?
A software firm builds something and hands it over. We build it with your team, so that the knowledge stays with you, and we are not an outsourcing house. If what you want is a supplier to build and disappear, we are probably not the right fit.
How much testing and security is included?
A minimal, focused set of tests agreed with the owner, and a best-practice baseline security setup. The agent has its own identity and only the access it needs. This sprint is not an evaluation or security exercise, so a deeper programme of either is separate work.
Ready to turn a use case into a working agent?
If you have a use case with an owner, a clear scope and real backing, that is a conversation worth having. Fill in the details and we’ll send you the full description of this engagement, including what deliverables you should expect from us. If that aligns with your goals, then we can schedule a first call to work out the details.
