Journey: Install A Full AI Agent Workflow The Way You Install An App

Here is a position I will defend for the rest of this article: the prompt is the wrong unit for sharing work between AI agents, and clinging to it is quietly costing businesses more time than any weak model ever did. I am Madhuranjan Kumar, and I think the arrival of Journey, a registry where whole agent workflows are packaged as installable kits, exposes just how brittle our current habit of copying long prompts really is. Most people believe better prompting is the answer to unreliable agents. I think that belief is holding teams back, and I want to argue why.

The prompt was never meant to carry a whole workflow

Start with what actually happens when you build something useful with an agent. You figure out a clever way to make it handle a repetitive job. It works on your machine, with your setup, after a dozen small corrections you barely remember making. Then a teammate wants the same result, so you hand them the prompt. They paste it in, and it does not work the same way. The context that made your version succeed, the tools, the fixes, the memory of what broke last time, none of that travels inside a block of text.

This is the core of my argument. A prompt is a description of intent, and a workflow is a working system. We keep pretending the description is the system. It is not. When you copy a prompt, you copy the words and throw away everything that made the words succeed. The reason so many agent projects feel unreliable is not that the models are dumb. It is that we insist on transporting real, stateful workflows through the flimsiest possible container.

A kit carries the things a prompt silently discards

Journey's answer is to package the whole workflow as a kit, and once you see what a kit contains, the prompt starts to look absurd by comparison. A kit bundles the skills, the tools, which are really small pieces of code, the memories, the external services the workflow talks to, the tests, and even the failures someone already solved along the way. Think of it the way you think of an app store, except instead of apps it ships whole workflows, and instead of installing onto your phone it installs onto your agent.

That last item is the one I care about most: the failures already overcome. Every real workflow is scar tissue. It works because someone hit a wall, found the fix, and hit another wall, and found that fix too. When you hand a colleague a prompt, they get none of that scar tissue and they get to rediscover every wall themselves, burning tokens and hours reproducing problems you already solved. A kit carries those solved problems inside it, so the next agent starts where you finished instead of where you began. A prompt cannot do that, and no amount of prompt engineering will fix a container that structurally cannot hold state.

Installing beats describing, and that is the whole point

The counterargument I hear is that a good enough prompt, with enough detail, gets you most of the way. I disagree, and the way Journey installs a kit shows why. You point your agent at the kit, and it downloads the whole package, learns how to use it, and even knows the edge cases. There is also a command line path for people who prefer it, and the same kit adapts to whatever agent environment you already run, so it works across different setups without you rewriting anything.

Compare that to the prompt workflow: describe, paste, debug, describe again. Describing is lossy by nature. Installing is not. When you install, the working system arrives intact, dependencies and all. A kit even lists what it needs to run, an API key, a runtime, a command line tool, an embeddings model, and you can swap any of those, including for a local option. That is a fundamentally more honest way to move work between agents than hoping your prose was complete enough. The person who keeps refining prompts is polishing the wrong object.

Versioning is the feature that ends the copy paste chaos

If you have ever run a team where three people each have a slightly different version of the same prompt, you already feel this problem. Someone tweaked theirs, someone else never updated, and now the same task produces three different results depending on whose copy you grabbed. This is the natural end state of sharing workflows as text. There is no source of truth, only drift.

Kits are versioned like proper software. When an author ships an update, your agent gets a notification and asks whether you want it, and you can see exactly what changed before you upgrade. On top of that, agents report back what worked on their specific machine, and those learnings feed into the kit so it quietly improves for everyone. This is the part that turns my critique of prompts from a complaint into a real alternative. A prompt gets worse as it spreads, because every copy drifts. A kit gets better as it spreads, because every install can feed a fix back. That asymmetry is the whole argument in one sentence.

The team layer is where the prompt approach truly collapses

My position gets strongest at the organization level. An organization on Journey can share workflows while every person keeps their own agent, and a kit can point to shared resources like one common database or one set of credentials stored in a single place. Journey does not hold those secrets itself, it just points to where they live, so the whole team works off the same context instead of splitting into private, divergent copies.

Now contrast that with a team sharing prompts. There is no shared context, only a chat thread full of pasted text and screenshots that goes stale the moment anyone improves their version. The prompt approach does not scale past one person, and I would argue it barely scales to one person over time, because even you forget which version of your own prompt was the good one. A team that shares kits shares a working, versioned, self improving system. A team that shares prompts shares confusion with extra steps.

A worked example: the followup an HVAC company kept losing

Let me make this concrete, because the abstract case is easy to nod along to and hard to feel. Picture an HVAC company and a kit called something like service call followup. Every time a technician closes a job, the kit reads the ticket, drafts a friendly followup asking how the new system is running, flags any unit still under warranty, and schedules a reminder for the next maintenance window. All of that logic, including the small fixes that took a few tries to get right, lives inside one installable package.

Under the old prompt approach, the owner would write a clever followup prompt, and the dispatcher, the service manager, and the front desk would each get a copy. Within a month those copies would diverge. One person tightened the wording, another never got the warranty check working, a third pasted an old version. Half the office would be running a slightly broken followup, and the company would keep leaking repeat maintenance revenue to forgotten calls, the exact problem the prompt was supposed to fix.

With a kit, the owner installs it once and shares it across the office. Every agent runs the identical workflow, all pointed at the same customer database, feeding results into the CRM and website stack where the reminders and next touches actually get scheduled. When a teammate's agent discovers that a certain message wording books more tune ups, that learning flows back into the kit and everyone benefits at once. When the owner refines the warranty logic, the team gets a version notice and upgrades together. Consistency stops being a hope and becomes the default.

Now put illustrative numbers on it, because the time cost is the real argument. Say setting up a new workflow by hand, from a fresh prompt through all the debugging, takes around two hours per person. Across a small team that is a painful, repeated tax every time the process changes. With a kit, the first install and test might take forty minutes, and by the time the workflow is mature the marginal setup for each new person drops to roughly ten minutes, because they are installing a finished system rather than rebuilding one. Those figures are illustrative, but the direction is the entire point: prompts make every share expensive, kits make every share cheap, and cheap sharing is what finally lets a workflow spread without rotting.

The objection I take seriously, and where it stops

Let me steelman the other side, because there is one version of the prompt argument worth respecting. A skilled operator with a single agent, working alone, can get a very long way on prompts. If you never share your work and never need to reproduce it on a different machine, the overhead of packaging a kit might genuinely outweigh the benefit. For a solo tinkerer running one workflow that they fully understand and rarely change, a good prompt really can be enough. I will grant that.

But notice how narrow that carve out is. It requires you to work alone, to never onboard anyone, to keep everything on one machine, and to rarely change the workflow. The moment any of those conditions breaks, and in a real business they all break quickly, the prompt approach starts leaking. Add a second person and you get drift. Change machines and you get missing dependencies. Improve the process and you get three stale copies. The prompt is only sufficient in the one situation where sharing does not matter, and sharing is the entire reason we build reusable workflows in the first place.

There is also a subtler cost that the prompt defenders miss. Even a solo operator is really working with their future self, who will not remember why the workflow was written the way it was, which fixes were load bearing, or which version was the good one. A kit preserves that reasoning as installable state. A prompt preserves only the words, and words without their context rot the same way for you in six months as they do for a colleague today. So even the strongest case for prompts, the lone expert, quietly benefits from packaging, because packaging is really just being honest that a workflow is more than its description.

That is why I hold my position even against the best objection. Prompts are fine exactly where sharing and continuity do not matter, and those are precisely the situations that do not need a reusable workflow at all. Everywhere a workflow is actually worth keeping, the prompt is the wrong container and the kit is the right one.

Why this matters beyond one clever tool

I am not arguing that Journey specifically is the only answer. I am arguing that the idea behind it, moving from describing workflows to installing them, is the correction our whole approach to agents needs. The same content and process foundation that a well built kit standardizes also strengthens the rest of your stack, from the campaigns you run on Facebook and Instagram ad campaigns to the pages that support SEO and organic search, because consistent processes produce consistent output everywhere they touch.

If you want to apply this yourself, start by writing down one workflow you already repeat by hand, step by step, including the spots where it usually breaks. Then stop trying to perfect the prompt for it. Package it, or install someone else's kit for it, and let the working system travel instead of the description. You can absolutely tinker your way there alone if you enjoy it. If you would rather skip the trial and error and have a clean, reliable workflow set up and handed to your team, that is exactly the kind of thing my team and I do, and a short call is the fastest way to map it out.