Meridian Line's four assistants -- charter desk, customs compliance, port operations, and maintenance triage -- each currently have their prompt text hardcoded inline in separate notebooks, and a shared instruction (always cite the source document) has drifted out of sync across them after several edits. What development practice addresses this?

Treating shared prompt fragments as reusable, versioned components -- a small prompt template or registry that each assistant's chain references rather than a hand-copied instruction pasted into four notebooks -- is standard prompt-development practice once an instruction needs to stay consistent across multiple applications; it turns 'edit four places correctly' into 'edit one place correctly,' which is exactly the failure mode described. Leaving the prompts hardcoded and separate is what produced the drift in the first place and does nothing to prevent it from recurring on the next edit. Merging all four assistants into a single prompt was already rejected earlier in this bank as the wrong response to shared infrastructure needs -- it reintroduces the unfocused, overloaded-prompt problem for the sake of solving a much smaller consistency problem that a shared template solves without that cost. Asking each assistant to generate its own citation instruction at inference time is nondeterministic and unverifiable -- there is no guarantee the four independently generated instructions stay equivalent, and it reintroduces exactly the consistency risk the fix is meant to eliminate, at the cost of extra latency and tokens on every call. Exam framing: developing and iterating prompts, including keeping shared instructions consistent across applications, is Section 3 Application Development work distinct from the one-time act of writing a single good prompt.