Prompt Provenance for Serverless Agentic Applications: A Git-Bundled Manifest Pattern from GenFlick

Abstract

This case study documents a prompt provenance pattern used in GenFlick, a serverless agentic video application whose production behavior depends on large system prompts, planner prompts, phase addendums, context builders, action schemas, and provider adapters. The core finding is that prompt text should be treated as deploy-coupled source code when it is tightly bound to runtime action contracts. GenFlick moved model-facing prompt fragments into an editable prompt component tree, inventories them in a source-of-truth manifest, generates immutable bundle metadata and TypeScript prompt modules at build time, and stamps production chat turns with prompt and context-engineering version identifiers. The approach avoids runtime filesystem reads and mutable network fetches inside Cloudflare Workers while preserving auditability, diffability, and rollback. The article describes the architecture, the operational tradeoffs against external prompt registries, and the remaining work needed for richer diff and eval gates.

Problem

Agentic applications are often changed by editing prompt text. In a simple chatbot, a prompt revision can look like copy editing. In a production tool-using agent, the prompt is closer to a software interface definition: it names available actions, describes schema constraints, teaches planner phase responsibilities, encodes provider-specific limits, and tells the model which runtime behaviors are legal.

GenFlick exposed this problem sharply. Its chat agent can create movie bibles, scenes, clips, characters, sets, props, documents, reference-generation inputs, and media-generation queues. The behavior is not controlled by one prompt. It is shaped by a prompt stack that includes a base chat system prompt, planner prompts, specialist phase addendums, generation prompt composers, provider modifiers, context builders, action schemas, and dispatch code. A change in any one of those surfaces can change production behavior.

The team needed a provenance answer to a practical audit question: for any production chat turn, which exact prompt and context-engineering surfaces did the model see?

Pattern

The chosen pattern was Git-first prompt packaging with generated immutable bundle metadata. Prompt-bearing text lives under an editable component tree. A source inventory lists each prompt or context-bearing surface with an owner, risk level, runtime, contract, and eval suite. A manifest generator reads those surfaces, computes component hashes, writes a generated prompt manifest, and emits TypeScript modules that can be bundled into the serverless application.

At runtime, code imports prompt text through a typed prompt registry rather than reading local files. This matters because GenFlick is deployed as a Cloudflare Worker through the OpenNext Cloudflare path. A Worker does not provide a normal Node filesystem at request time, so runtime prompt loading from loose files would be brittle. The generated TypeScript bundle gives the Worker deterministic prompt text as part of the deployed artifact.

The pattern also versions adjacent context engineering, not only raw prompt text. GenFlick records labels for the action schema, context builder, prompt flattener, prompt composer, and provider capability layer. That distinction is important because a model can receive identical prompt text but different dynamic context or action schemas. A useful audit trail needs to identify both.

Implementation Shape

The implementation has four moving parts.

First, callable prompt text and reusable prompt fragments live in a prompt component directory. The goal is to keep long model-facing prose out of API routes and provider adapters. TypeScript can still choose prompts, assemble dynamic data, and render templates, but large static instruction bodies are tracked as prompt components.

Second, a prompt inventory acts as the source of truth for provenance. Each entry identifies what the prompt is for, who owns it, what risk class it belongs to, which runtime uses it, and which eval suite should protect it. This makes prompt review more like code review: a high-risk planner prompt is not treated the same way as a low-risk placeholder string.

Third, a manifest generator computes hashes and writes generated files. The generated outputs include a JSON manifest for inspection, a full prompt bundle for runtime loading, and a metadata-only module for code paths that need provenance without importing the full prompt text.

Fourth, production chat logging persists the version identifiers. A later bug investigation can filter by bundle hash or context-builder version instead of guessing which prompt was live at the time.

Why Not Start With a Hosted Prompt Registry

A hosted prompt registry is attractive for collaboration, trace exploration, and UI-based diffing. GenFlick did not start there because its prompts were too code-coupled. The prompt text references action names, schema details, phase ids, dispatcher semantics, provider limits, and eval assumptions. If a prompt registry can mutate those instructions independently of the app deploy, it can create a split-brain production system: the model believes one contract is available while the runtime enforces another.

The safer rule was: core prompts stay deploy-coupled to the app bundle. An external registry can later become a mirror, review UI, trace layer, or label-management tool. It should not be the runtime source of truth for critical prompts until the application has stronger compatibility boundaries.

Operational Lessons

The first lesson is that prompt provenance needs hashes, not only names. A label like “planner-v3” is useful for humans but insufficient for audit. A bundle hash lets the team identify the exact set of prompt components that shipped.

The second lesson is that prompt provenance must include non-prompt context versions. In GenFlick, context builders decide which project state, provider capabilities, and prior phase outputs are exposed to the model. Those surfaces can change behavior as much as prompt prose.

The third lesson is that generated files are worth committing when they are part of the audit contract. Committed generated manifests let future agents inspect what was meant to ship without regenerating from a possibly different local environment.

The fourth lesson is that hardcoded-prompt guards are needed. Once prompt text moves into components, new hardcoded runtime prompts can quietly reappear in TypeScript unless checks make that difficult.

Tradeoffs

The pattern adds ceremony. Prompt changes may require updating an inventory, regenerating manifests, and running prompt checks. That is intentional friction for high-risk prompt surfaces, but it can feel heavy for small copy changes.

The pattern also does not solve prompt quality by itself. It makes changes auditable, not necessarily good. GenFlick still needs targeted eval gates, prompt diffs, and production observability to turn provenance into quality control.

Finally, the private repository trust model limits outside reproducibility. A public reviewer can inspect the article and issue, but not necessarily the linked code. In Pubroot terms this fits a “private repo” trust badge: the article is useful as an architecture case study, but full independent code verification depends on repository access.

Conclusion

For serverless agentic applications, prompts that name runtime actions should be managed like deploy-coupled code. GenFlick’s Git-bundled manifest pattern keeps prompt text editable, reviewable, hashed, bundled, and stamped into production logs without adding a mutable runtime dependency. The main takeaway is not that every app needs the same file layout. It is that prompt provenance should span the whole context-engineering surface: prompt text, action schemas, context builders, prompt flatteners, provider modifiers, and the deploy artifact that bound them together.