The question behind the experiment
Most consulting runs on handoffs. A client describes what they want, someone writes it down, it gets re-described in a proposal, re-described again in a ticket, built, tested, and finally handed back, usually with a few meetings and a few misunderstandings along the way. Each handoff is a place where intent leaks.
AI is changing the cost of building software. The more interesting question is what it does to everything around the build: how work is briefed, quoted, tracked, delivered, and trusted. So instead of writing about it, we built it and ran it with a live customer.
The goal was simple to state and hard to do well: let a client and their own AI agent initiate, receive, test, and refine platform changes natively, with as little human translation in the middle as possible. This is a field note on what happened when we tried.
What we built
The experiment had three parts, each useful on its own, and considerably more interesting together.
1. A structured operating spine
The first piece was a structured operating spine for the consulting relationship: briefing, quoting, invoicing, payments, and case management. Nothing exotic, and deliberately not the point of the story. The important decision was to make a “request,” a “brief,” a “quote,” and a “deliverable” first-class objects the system could reason about, rather than free text trapped in email threads.
Owning that spine is what made everything after it possible. When the unit of work is structured, software can act on it.
2. An AI assistant interface, so clients bring their own agent
On top of that spine we built an AI assistant interface that lets clients interact with Helikona through their own AI agents, natively. The client doesn’t log into our portal to fill in a form. Their agent talks to our system on their behalf, submitting requirements, raising issues, and checking status, in the same conversational flow they’re already using to think through the problem.
This is the part that changes the texture of the relationship. The client is no longer translating their intent into our format. Their agent does it, against a structured interface, with the original context still attached.
3. An AI-driven CI/CD pipeline
Behind the scenes, we built a development pipeline that uses Slack and a work management system combined with automated development. Inbound work lands in Slack, gets logged as a work item, and kicks off an automated build-preview-test-release cycle. The pipeline is where a logged change request becomes a previewed, tested, released version of the software, and then notifies the client that it’s ready.
Individually these are three sensible pieces of infrastructure. The experiment was seeing what happens when you connect them end to end.
The straight-through process, with a live customer
We ran the full loop with a real client building a real platform. Here is the cycle we observed, end to end:
1. The client develops requirements with their AI agent, then asks it to submit them to Helikona. The thinking and the specification happen in the same place. When the requirement is ready, the client doesn’t copy it into a portal. They ask their agent to send it to us.
2. The change request and any fixes notify in Slack. The pipeline logs them in work management before kicking off development. Nothing waits for a human to notice an email and open a ticket. The arrival of the request is the start of the work.
3. The requirement is built, previewed, tested, and released back to the client. The automated pipeline takes the logged work item through development, generates a preview, runs tests, and cuts a new version, then notifies the client that the change is live.
4. The client tests in their own environment. When they find an issue, their agent submits it back to Helikona. The same loop runs again: Slack notification, work management log, automated development, preview, test, release, notify.
The result is a closed loop where a client can initiate a platform change and receive it back as working software, with their agent and our pipeline doing most of the carrying. The proposal, the ticket, the build, and the release stop being separate conversations. They become one continuous motion.
What we noticed
A few characteristics stood out once the pieces were combined. They are the kind of thing you only see by running it, not by diagramming it.
The handoffs collapsed. The traditional gaps (request to brief, brief to ticket, ticket to build, build to delivery) were where intent used to leak and time used to disappear. When the client’s agent submits against a structured interface and the pipeline acts on it directly, most of those gaps simply close. The request keeps its original context all the way through.
Intent survived the journey. Because the client specified the change with an agent and that same agent submitted it, the requirement arrived with its reasoning intact rather than flattened into a one-line ticket. The build had more to work with, and there was less back-and-forth to reconstruct what was actually meant.
The feedback loop got tight enough to feel like a single tool. Test, find an issue, submit, receive a fix. The cycle ran fast enough that the boundary between “our software” and “their software” started to blur. For the client, raising an issue felt less like filing a support request and more like editing something they already owned.
The work around the build became the real work. This is the pattern we keep seeing. AI compressed the build cycle so effectively that the interesting questions moved elsewhere: how a change is briefed, how trust is maintained when releases are this fast, how scope and price get negotiated when the software can change this easily. The product stopped being the slowest part of the system, so the system around it is where the attention now goes.
Why it matters for clients
For organisations and technical leaders deciding where AI actually fits, this experiment points at something concrete rather than aspirational.
It shows that the bottleneck in delivery is often not the building. It is the translation, the waiting, and the handoffs. Remove those and a small practice can respond to change at a speed that used to require a much larger team. It also reframes the relationship: when your agent can talk to your supplier’s pipeline directly, the supplier stops being a black box you submit tickets to and becomes something closer to an extension of your own workflow.
And it makes the pitch tangible. Rather than describing what AI-native delivery could look like, we can show a working version of it: initiate a change, watch it travel through the pipeline, receive it back as a released version. That is the shift we think AI is bringing to professional work, from “here is what we would do” to “here is a working version; do you want to make it real?”
Beyond software: where this pattern goes
The straight-through process is built and running inside Helikona. We use it. What it isn’t yet is a product we’ve packaged for others, and that gap is deliberate, because the more valuable discovery isn’t the software pipeline itself. It is the underlying pattern.
Strip the loop back to its mechanics and nothing about it is specific to code. A structured unit of work, a client who specifies intent with an agent, a system that acts on that intent directly, and a tight loop of preview, review, and release: that shape applies to almost any knowledge work where the output can be drafted, shown, corrected, and shipped. The software case was simply the cleanest place to prove it, because software already had the scaffolding: tickets, versions, pipelines, tests.
So the question we’re now exploring is what this same straight-through process does to the other kinds of work consultancies and agencies sell:
Creative and marketing work. Today a brief becomes a concept, a concept becomes a round of revisions, and revisions become more meetings. If a client can develop a campaign brief with their agent, submit it natively, and receive finished or near-finished assets back to react to, the pitch stops being a deck of ideas and becomes a set of working artefacts. The conversation moves from “here’s what we’d make” to “here’s three versions; which one do you want in market?”
Design work. The same collapse of handoffs applies to design systems, mockups, and prototypes. When intent arrives with its reasoning intact and the loop from request to rendered design is tight enough to feel like a single tool, the client stops filing change requests against a design and starts shaping something they already feel ownership of. It is exactly what we saw happen with the software client.
Knowledge work more broadly. Anywhere the work is specify, produce, review, revise, deliver (research, documentation, analysis, strategy artefacts), the same bottleneck holds: it was rarely the producing that was slow. It was the translation, the waiting, and the handoffs. The pattern removes those.
These aren’t hypotheticals on a slide. They’re the experiments we have in flight now: taking the loop that works for platform changes and running it against creative, marketing, and design work to see where it holds and where it breaks. The honest answer is that some of it will break, and the breakages are the interesting part: how trust and review hold up when output is this fast, how scope and pricing work when the artefact is this easy to change, and where a human should deliberately stay in the loop rather than be automated out of it. That judgment becomes more valuable as the production cycle compresses, not less.
If your team is past the demo stage and trying to work out what changes when AI is wired into how work actually gets initiated, delivered, and trusted, whether in software or in creative, marketing, and design, that is the conversation we’re most interested in.
Helikona helps organisations and technical leaders turn AI capability into strategy, working prototypes, and clearer ways of working, through short, focused engagements that diagnose, design, build, and recalibrate.
Implementation note: in the live version, Slack is the primary human interface and Jira is the software engineering work-management system. A CI/CD pipeline runs build and test work through just-in-time test environments with stateless databases seeded from synthetic data on cloud infrastructure. OpenAI and Anthropic models are used for agentic coding, and Salesforce remains the master of customer identity.