Personas and Agents: The Early Experiments

If you want a model to behave consistently across a long engagement — maintaining a specific perspective, applying a specific methodology, staying within a defined scope — you give it a persona. That's the idea, anyway. The execution turns out to be more interesting than the idea.

I started experimenting with persona-driven AI interactions alongside the knowledge system work. The timing wasn't coincidental: the same problem that drove the knowledge system — stateless models that lose context between sessions — drove the persona work. A persona is a form of persistent context. Get it right and the model behaves like a specialized collaborator. Get it wrong and you have an elaborate prompt that produces inconsistent output and a false sense of reliability.

What Personas Actually Are

A persona in this context is a system prompt that defines a role, a behavioral profile, and a set of constraints. Not a character in the theatrical sense — a functional specification for how the model should approach a class of tasks.

Here's an example from early experimentation:

You are a senior data engineer with deep experience in pipeline
architecture and data quality. Your role in this engagement is to:

1. Review proposed pipeline designs and identify failure modes
2. Flag data quality risks before they reach production
3. Apply the project's agreed patterns consistently (see project context)
4. Challenge assumptions that haven't been validated against real data

You do not:
- Generate code for tasks outside your review scope
- Accept "it works in dev" as sufficient validation
- Recommend solutions you cannot defend with observable evidence

When reviewing a design, lead with the highest-risk failure mode.

That's a functional persona. It defines what the model does, what it doesn't do, and what the output format should look like. Paired with the knowledge system providing project context, a session using this persona produced noticeably more focused output than a generic ChatGPT session on the same material.

The Copilot Integration

GitHub Copilot doesn't support system prompts in the traditional sense — it's an autocomplete engine, not a conversational system. But GitHub Copilot Chat does, and that's where the persona work initially landed. In the early months, Copilot Chat with a well-crafted system prompt behaved like a project-aware technical reviewer that understood the codebase I was working in.

The combination worked better than I expected. The system prompt gave the interaction shape and consistency. The editor context gave it project specifics. The result was a review conversation that stayed on topic, applied the right standards, and didn't need to be re-briefed about the project's architectural decisions every session.

I built several personas for different stages of my work:

• A pipeline architect for design review and tradeoff analysis
• A data quality reviewer for identifying edge cases and validation gaps
• A code reviewer for implementation review with project-specific standards
• A documentation writer for producing decision records and handoff notes

Each persona had a distinct behavioral profile and a distinct scope. Keeping them separate meant each one stayed in its lane — the code reviewer didn't try to redesign the architecture, the architect didn't nitpick variable names.

What Was Working

The consistency improvement was real and measurable. A session with a well-defined persona produced output that was more predictably shaped than a generic session. The model's responses stayed within scope. The reasoning followed the persona's declared methodology rather than improvising a new approach each time.

The project context injection — Cortex Forge surfacing relevant knowledge at session start — amplified the effect. A persona without domain context was consistent but generic. A persona with good domain context was consistent and specific. Specific enough that I was reviewing its outputs for correctness rather than for coherence.

This was the configuration I had been aiming for since month one: an AI interaction that felt like working with a specialized collaborator who understood the project. It had taken most of a year to build the underlying systems that made it possible. The result was worth the investment.

The Early Warning Signs

The warning signs appeared around month four of running the persona system. Not dramatic failures — subtle degradations that were easy to miss at first and impossible to ignore once you'd seen enough of them.

Models get updated. When a model update changed the underlying behavior of Copilot Chat, persona prompts that had been working reliably started producing different output. Not wrong output — different. The persona's behavioral constraints were being applied inconsistently, as if the new model version weighted the system prompt differently than the old one.

The scope discipline was also proving harder to maintain than the persona prompts implied. A code reviewer persona would, under certain prompting conditions, slide into architecture recommendations. The pipeline architect would start writing implementation code if the question was framed as "how would you implement this?" rather than "how should this be designed?" The personas were guidelines, not hard constraints.

These weren't problems I could solve by writing better prompts. They were properties of how the underlying models were behaving, and I didn't control that. That realization was the beginning of a different line of inquiry — one that would lead me away from persona prompts and toward something more robust. As always, I'm here to help if you want to compare notes on how you've handled persona consistency.