Who Owns Your Prompt Library?

A senior marketing manager at a mid-sized SaaS company spent four months building an agentic content pipeline. She connected Clay to Relevance AI to her company’s CRM, wrote the orchestration prompts, tuned the scoring logic, debugged the edge cases where the agent misrouted leads, and eventually got the whole system to a point where it ran a prospecting workflow in under a minute that used to take her team half a day. When she handed in her resignation last month, her manager asked a question neither of them had an answer to: does that pipeline belong to you or to us?

The question sounds simple. The answer touches employment law, intellectual property doctrine, the economics of tacit knowledge, and a category of professional capital that employment contracts were never designed to address.

The invention assignment gap

Most knowledge workers in technology companies sign invention assignment agreements as part of their employment contracts. These agreements typically assign ownership of any intellectual property created during employment, using company resources, to the employer. The language is broad and was written primarily to cover patents, software code, and trade secrets. It captures prompts, workflows, and agentic orchestration logic by default, because these agreements were designed to be maximally inclusive.

The problem is that the category of work these agreements were written to cover and the category of work that agentic AI has created are meaningfully different. Traditional IP assignment covers discrete outputs: a piece of code, a design, a documented process. What the marketing manager built is something closer to an operational intelligence, a system of prompts, decision logic, and integration architecture that functions as a kind of embedded expertise. The value isn’t in any single prompt. It is in the accumulated understanding of how to make a complex multi-tool workflow produce reliable results.

This is the gap. Employment agreements assign ownership of the artefacts. But the thing that makes agentic workflows valuable is not primarily the artefacts. It is the knowledge of how to build and tune them, which lives in the person who did the building, not in the files they leave behind.

What you can take and what you can’t

In practice, the legal position is reasonably clear on the extremes and entirely unresolved in the middle.

You cannot take proprietary company data, customer lists, or trade secrets. If the workflow you built processes company-specific data through company-owned tools using company API keys, the instantiated system belongs to the company. This is not controversial.

You can take general skills and knowledge. If you learned how to build agentic workflows, how to structure prompts for multi-step reasoning, how to evaluate agent reliability, those capabilities are yours. No employment agreement can assign ownership of your professional development, and courts have consistently held that general skills and knowledge acquired during employment belong to the employee.

The middle ground is where it gets interesting, and where nearly everyone currently operates without clarity. A prompt template that encodes your accumulated understanding of how to make a specific type of agent behave reliably: is that a trade secret, a creative work, or a transferable skill expressed in text? An orchestration architecture that routes decisions across multiple AI tools in a specific sequence: is that proprietary process IP, or is it the kind of operational knowledge that any experienced practitioner would develop independently?

The clear answer is that the legal frameworks have not caught up. Contract law, trade secret doctrine, and employment IP assignment were built for a world where the boundary between “what you made” and “what you know” was clearer. Code is an artefact; you can see it, version it, assign it. The knowledge of how to architect an agentic workflow is simultaneously an artefact (the prompt files, the configuration) and a capability (the understanding that produced them). Employment law does not handle this duality well.

The practitioner’s dilemma

For the person changing jobs, this creates a practical dilemma that has real career consequences.

If you document your agentic workflows meticulously, you create company-owned IP that your employer can continue to use and that you cannot take with you. The artefacts stay. You become replaceable, at least in theory, because the system is documented well enough for someone else to operate it.

If you keep the knowledge largely tacit, embedded in your own understanding rather than in comprehensive documentation, you retain more of the value when you leave. But you also make yourself harder to replace in ways that create friction with your current employer, and you produce less value for the organisation while you’re there because the system depends on your presence.

Most practitioners I talk to are navigating this without conscious strategy. They document enough to be effective in their current role and keep the deeper architectural understanding informal. This is not a deliberate IP strategy; it is simply what happens when people build complex systems under time pressure. But the effect is a kind of accidental moat: the documented system works, but the knowledge of how to evolve it, debug it when conditions change, and extend it to new use cases leaves with the person who built it.

What changes from here

Three things are likely to shift as agentic work matures and organisations begin to recognise the scale of the IP question.

Employment contracts will get more specific. The current generation of invention assignment clauses is too broad to be useful for this category of work. Expect to see contracts that explicitly address prompt libraries, agent orchestration logic, and workflow architectures, with more granular distinctions between company-specific implementations and transferable methodology.

Practitioners will develop more deliberate strategies for managing their portable expertise. Right now, most people who build agentic workflows do not think of themselves as creating intellectual property. That will change as the market begins to price this skill set and as the gap between “can configure AI tools” and “can architect reliable agentic workflows” becomes visible in hiring and compensation.

The most interesting question is whether agentic workflow expertise develops the same professional dynamics as other forms of tacit operational knowledge, or whether it creates something new. A CFO who leaves a company takes their financial modelling expertise with them but leaves the specific models behind. An agentic workflow architect occupies a similar position, except that the ratio of tacit knowledge to documented artefact is different, and the artefacts are simultaneously more portable (text files, not enterprise software) and more entangled with company-specific context (tuned to specific data, specific tools, specific business logic).

The marketing manager took her resignation and left behind a documented pipeline. Her new employer will benefit from her ability to build something similar, tuned to a different context, with different data, probably better than the first one because she has done it before. Her former employer has the pipeline but will discover, over the next few months, that the documented system is the least valuable part of what she built. The question of who owns the prompt library matters less than most people think. The question of who carries the knowledge of how to build the next one matters more.