Turning vague agent personality goals into versioned prompts with Amazon Bedrock

Learn a structured methodology to translate vague personality requirements into testable behaviors and versioned prompts for conversational AI assistants using Amazon Bedrock.

“Make it friendly but professional.”

Teams building conversational AI assistants on Amazon Web Services (AWS) hear variations of this request constantly. It hides a vagueness problem common in responsible AI: marketing interprets “friendly” as warm and proactive, legal interprets it as using accessible language rather than dense terminology, and engineering needs concrete instructions to build anything at all.

Each function agrees with the slogan while meaning something different by it. Without a structured translation process, the loudest voice wins, and the resulting assistant behaves inconsistently from one interaction to the next, which surfaces later as user complaints, brand inconsistency, and rework cycles.

The methodology described in this post translates subjective personality requirements into testable behaviors, versioned prompts, and documented boundaries. It addresses several dimensions of Responsible AI at AWS, an eight-dimension framework for building and evaluating AI systems.

Specifically, the methodology contributes to controllability (predictable, steerable behavior), fairness (culturally appropriate responses across user populations), safety (enforced boundaries), and transparency (a shared reference that captures intended use and limits).

Public sector deployments raise the bar on personality design: The assistant must be culturally appropriate for diverse populations, transparent about what it can and can’t do, and consistent in tone across high-stakes interactions.

The methodology consists of three phases: Discovery, Technical translation, and Validation. To make each phase concrete, we use a running example of a government assistant that helps citizens navigate public procedures (document issuance, appointment scheduling, application status). This is illustrated in the following table:

Figure 1: Three-phase personality design methodology

Phase 1: Discovery

Before writing any prompt, the most important step is a structured conversation with stakeholders to translate their vague personality requirements into specific, agreed-upon behaviors.

The personality identification workshop

Rather than asking abstract questions such as “how should the assistant sound?”, we use a structured exercise with adjective cards. As facilitator, you prepare a deck of 20–30 adjectives organized by category (Warmth, Formality, Energy, Authority, Humor) and run the workshop with product owners, UX designers, brand managers, and at least one representative end user if possible.

The exercise has four parts:

1. Selection – Stakeholders pick five to seven adjectives that best represent the desired personality.
2. Exploration – For each selected adjective, participants describe what that trait would look like in a real response. “What would it sound like for the assistant to be empathetic?” Some participants articulate this naturally; others need help. Showing a concrete example contextualized to the use case, prepared in advance by the facilitator, often unlocks productive reactions because people can more readily refine something specific than describe what they want from scratch.
3. Negative boundaries – Stakeholders identify adjectives the assistant should explicitly avoid, and describe what those would sound like.
4. Validation – The group reviews selected and avoided traits to confirm shared interpretation, paying special attention to adjectives introduced outside the original deck. A word such as “elegant” can mean different things to different people, and this is where those differences surface.

Identifying regional and cultural language patterns

Language isn’t universal even within the same language. A government assistant in the American South needs different vocabulary than one for users in the United Kingdom, and a Spanish-speaking assistant for residents in Mexico City needs different formality markers than one for users in Buenos Aires. For public sector services that must reach diverse populations, this isn’t a stylistic choice. It determines whether all citizens receive the same quality of service.

Conduct casual conversational interviews with representative end users. Whether those users are external (citizens accessing public services) or internal (government employees and caseworkers) determines the conversation topics. For external-facing assistants, talking about everyday topics reveals authentic vocabulary without the pressure of a formal interview.

For internal-facing assistants, conversations can be closer to the use case itself because participants already share the domain vocabulary. From these conversations and complementary research in regionalism databases, the team produces a list of vocabulary preferences, formality expectations, common expressions, and words to avoid.

This step is where the methodology directly addresses fairness in its representation and quality-of-service dimensions. A government assistant that uses vocabulary unfamiliar to its target population, even if factually correct, produces a differential experience across user groups. A citizen who doesn’t recognize bureaucratic jargon receives less value than one who does, which is not only a usability issue but a fairness issue.

Documenting restrictions and limits

In parallel with the workshop, documentation addresses topics the assistant must not engage with, tone shifts required for sensitive situations (complaints, errors, bad news), regulatory constraints, and brand-specific prohibited terms.

Stakeholders often struggle to verbalize boundaries in the abstract. A useful facilitation technique is to present edge-case scenarios, which are situations where the right response isn’t obvious because the user’s request sits at the intersection of sensitive, ambiguous, or high-stakes topics, and ask stakeholders how the assistant should respond.

These scenarios can be generated with the help of a large language model (LLM) to speed up preparation. For the citizen services assistant, a probing scenario might be a user in visible emotional distress asking a purely procedural question, such as someone who has just lost a family member and reaches out asking how to obtain a death certificate. Walking stakeholders through scenarios like this surfaces boundaries that would otherwise remain implicit until production.

The level of restriction varies by use case. A citizen services assistant might provide procedural guidance but not legal interpretation. These distinctions are the inputs to safety controls that get enforced in Phase 2.

Output: the expected behaviors matrix

The Discovery phase produces a structured matrix mapping personality traits to specific behaviors across representative interaction scenarios:

The matrix is the bridge between stakeholder language and engineering artifacts. Stakeholders can review and modify the example responses if they feel the wording doesn’t match their intent. This is their last opportunity to fine-tune the voice before it reaches the prompt.

By the end of Phase 1, you’ve alleviated the vagueness. Every personality trait has a concrete behavior, every behavior has an example, and every boundary is documented. This is what gives the assistant controllability in the responsible AI sense: A team that can articulate the expected behavior of its system has the foundation for steering it.

Phase 2: Technical translation

With the personality defined in concrete terms, the team translates the behaviors matrix into a system prompt and operational controls.

Constructing the base prompt

The system prompt is where adjectives and behavior matrices become instructions for the model. Key elements include the assistant’s identity and role, voice directives, behavioral rules for specific scenarios, language constraints, and guardrails.

The AWS documentation on prompt engineering concepts is a useful reference for structuring these elements, but prompt engineering guides alone aren’t enough for personality work. The methodology described in this post complements those guides with the content that goes into the instructions.

The critical principle at this stage is to describe behaviors, not adjectives. Telling a model to “be empathetic” produces inconsistent results because the model has to interpret what empathy means in this context. Telling a model to “acknowledge the user’s feeling, reflect understanding, then offer a solution” produces consistent results because the pattern is explicit.

The following is a streamlined example of how personality traits translate into prompt instructions for the citizen services assistant:

You are a virtual assistant helping residents figure out what they need to do and how to do it based on how they describe their own life situations. Your job is to translate plain-language descriptions ("I just had a baby," "I lost my ID") into the right procedures and walk people through them step by step.

## Voice and tone

- Open conversations by inviting the user to describe what's going on in their own words. Never ask them for a form name, procedure code, or agency name they probably don't know. Make it clear from the first message that not knowing official terminology is normal and expected.

- When a user expresses frustration, confusion, or exhaustion with bureaucracy, first reflect that their experience is valid. Only then move toward a concrete next step. Do not skip the acknowledgment to get to the information faster.

- Convert every official term into a plain-language equivalent on first use. Lead with what an agency does, not its abbreviation. For example, say "the office that handles birth certificates" before naming it officially.

## Boundaries

Hard limits (never cross these):
- Do not provide legal advice or interpret legal texts for a user's specific situation.
- Do not make any assurance, explicit or implied, that a user is "completely safe" or free from legal or enforcement risk.
- Do not rank or recommend one program over another based on a user's personal circumstances. Explain how each works; the choice belongs to a caseworker or the user.

What you can do within these limits:
- Share factual, publicly documented policies and eligibility criteria. Clarify that sharing public information is different from a legal guarantee.
- Suggest a logical procedural sequence when a clear, practical reason exists (for example, updating an address before renewing a license).
- Interpret expressions like "I want to sue my landlord" as a request for procedural guidance, not legal strategy.

## When in doubt

- If you can't identify what a user needs, ask one follow-up question in plain language. Reassure them that not knowing what something is called is completely fine.

Each instruction traces back to a decision made during Discovery. Nothing in the prompt should be generic; every line reflects a specific decision about how this assistant should behave for this population.

Operationalizing the prompt on Amazon Bedrock

Personality prompts evolve, and the team needs to trace how and why. Amazon Bedrock Prompt Management provides a centralized workspace to create, store, version, and test personality prompts against the foundation model being evaluated. Each iteration is saved with its context and results so the team can roll back drifts and maintain a clear history of how the voice definition evolved. Versioning turns personality design into an auditable artifact, the operational side of controllability.

You can also reinforce the restrictions identified in Phase 1 at runtime using Amazon Bedrock Guardrails, which adds content filters, denied topic detection, and other safeguards that complement the prompt. Translating those restrictions into specific guardrail configurations is a natural next step for teams that want an additional safety layer at runtime.

Phase 3: Validation

With the prompt tested, the team returns to the original workshop participants with the prompt and example interactions from the implemented assistant. Validation can happen in a follow-up meeting or asynchronously through email depending on what works best for the stakeholders.

A practical validation technique is to run the scenarios from the behaviors matrix through the current prompt and present stakeholders with both outputs side by side: the example response they approved in Phase 1, and the response the assistant actually produces with the current prompt.

Stakeholders can decide which one is better aligned with their intent. This reframes validation from abstract judgment (“does this match what we asked for?”) to a concrete comparison (“is the generated response better or worse than the example?”), which produces sharper, more actionable feedback.

Feedback drives another iteration of the prompt in Amazon Bedrock Prompt Management, and the cycle continues until the assistant consistently reflects the agreed personality across the scenarios in the matrix.

Final outputs: the prompt and the assistant profile

The methodology produces two connected outputs: The first is the versioned system prompt, the technical artifact that runs in production and delivers the personality to users. The second is the assistant profile, a document that captures the main personality characteristics, specific behaviors, restrictions, limits, and other relevant attributes agreed upon during the process.

The prompt is the operational output; the profile is its explanatory companion. Together they answer two different questions: what does the assistant do (the prompt, testable and versioned) and what was the assistant designed to do and why (the profile, readable and auditable).

The profile serves a transparency function similar to a service card. It tells anyone working with the assistant, such as product managers, engineers, content designers, or external auditors, what the assistant is intended to do, how it’s meant to behave, and where its boundaries are. New team members can onboard from this document instead of reverse-engineering personality decisions from the prompt.

Conclusion

The methodology turns a vague personality request into concrete artifacts: a behaviors matrix that captures stakeholder agreement, a versioned prompt that delivers it in production, and an assistant profile that makes the design decisions readable for anyone who joins the project later.

It addresses several responsible AI dimensions through everyday practice: controllability through versioned and auditable prompts, fairness through cultural and linguistic research, safety through stakeholder-defined boundaries, and transparency through the assistant profile as a shared reference.

For public sector teams building assistants that interact with diverse citizen populations on high-stakes procedures, these dimensions aren’t theoretical. They translate directly into whether constituents trust the service and use it.

To learn more, refer to the Amazon Bedrock User Guide and Responsible AI at AWS. To engage with the AWS team on your own generative AI initiatives, contact your AWS account team or learn more about the AWS Generative AI Innovation Center.