diniscruz.ai / writing / Development and GenAI

Personas Service - Technical LLM Brief

By Dinis Cruz and ChatGPT Deep Research · · 21 min read

PDF

Contents · 7 sections
  1. Overview and Objectives
  2. Persona Definition Schema
  3. Service Modes of Operation
  4. Architecture and Integration
  5. Usage Example Walk-through
  6. Considerations and Future Enhancements
  7. Conclusion

Overview and Objectives

The Personas Service (to be deployed at personas.prod.mgraph.ai) is a stateless microservice that leverages Large Language Models (LLMs) to translate and tailor content for specific target personas. The core idea is to adapt a given message or query so that it is optimally communicated to or from a particular persona, taking into account that persona's language, background knowledge, role, and communication style. This service enables dynamic "persona-aware" translations without training custom models -- it uses existing LLMs via our LLM backend service (e.g. llms.prod.mgraph.ai) for all natural language generation.

Key objectives include:

By achieving these objectives, the Personas Service will function as a flexible "persona translator" -- bridging the gap between different knowledge domains, languages, and communication styles, ensuring the right message gets across to the right audience. In essence, it lets developers and systems translate a message for a target persona, or generate a response as if from a target persona, on the fly.

Persona Definition Schema

At the heart of this service is the Persona Definition -- a data structure that describes the key attributes of a persona. This definition guides the LLM in adjusting tone, terminology, and detail level for that persona.

A Persona Definition will likely be represented in JSON (or a similar structured format) and could include fields such as:

These fields collectively act as a profile that the LLM will use to adjust its output. By feeding such persona attributes into the prompt, the LLM can modulate its response accordingly. As one study on persona-based prompting explains, personas allow LLMs to adjust tone, language complexity, and style for different user types and preferences, leading to more user-centered communication[2]. The persona profile effectively tells the model "here's your audience or role, adapt to them."

Example Persona Definition (JSON):

{
  "id": "persona_ciso_pt",  
  "name": "CISO of ACME Corp (Portuguese)",  
  "role": "Chief Information Security Officer",  
  "language": "pt-PT",  
  "expertise": {
    "cybersecurity": "expert",
    "finance": "basic"
  },  
  "priorities": ["cyber risk reduction", "incident response", "technical accuracy"],  
  "communication_style": {
    "tone": "professional",
    "detail_level": "high",
    "style": "direct and technical"
  },  
  "urgency_preference": "immediate updates on major incidents"
}

Another example might be a Board Executive persona in English:

{
  "id": "persona_board_exec_en",  
  "name": "Board Member (Finance)",  
  "role": "CFO, Board of Directors",  
  "language": "en-UK",  
  "expertise": {
    "cybersecurity": "low",
    "finance": "expert"
  },
  "priorities": ["business impact", "regulatory compliance", "reputation risk"],  
  "communication_style": {
    "tone": "formal",
    "detail_level": "summary-focused",
    "style": "business-centric and concise"
  },
  "urgency_preference": "focus on key points first, follow-up details if needed"
}

These are illustrative; the schema can be refined. The key is that the persona profile provides enough information for the LLM to infer how to present or interpret information for that persona. The service will likely maintain a schema definition to validate persona objects. It may also include a version or timestamp if we plan to update personas over time.

Persona Storage and Retrieval: Since the Personas service itself is stateless, persona definitions are not permanently stored in the service instance. Instead, persona data can be:

Service Modes of Operation

The Personas Service offers two primary modes of operation, corresponding to two ways of using a persona profile with the LLM: (1) Translate to Persona, and (2) Respond as Persona. These fulfill different needs in the communication workflow.

1. Translate to Persona (Persona as Audience)

In this mode, the service takes an input message and rewrites or translates it for the target persona. The assumption is that the input content is written from a general or original perspective, and we want to tailor it so that the target persona will understand it fully and be addressed appropriately. Essentially, this treats the persona as the audience/recipient of the message.

Example: Consider the message about a ransomware incident affecting profit & loss.\ - For the CISO persona (Portuguese, cybersecurity expert), the original terms like "ransomware" are well-understood (no need to explain what ransomware means), but business terms like "P&L" might be unfamiliar. The service might output (in Portuguese) a message that still calls it "ransomware" but perhaps clarifies "impacting the financial results (lucros e perdas)" since P&L might need expansion. It would also likely include technical details (since a CISO would want to know specifics of the incident) and be fairly direct about the cybersecurity aspects.\ - For the Board Executive persona (English, finance expert), the service would do the opposite: it might not bother explaining "P&L" (because a CFO knows it means Profit and Loss), but it would explain "ransomware" in more accessible terms (e.g. "a type of cyber attack that encrypts data and demands a ransom"). The tone would be high-level, focusing on business impact ("it has caused downtime in Division X and could affect Q4 financials") rather than technical minutiae. It might be more formal and include a suggestion of actions or reassurances, fitting how one would brief a board member.

These tailored outputs ensure each persona gets the information in the way that makes sense to them. If the same original message is run through Translate to Persona for multiple personas, we get multiple versions, each appropriate for its audience. This is extremely useful in scenarios like incident communication, where different stakeholders (IT teams, executives, customers) must all be informed with the same base facts but with different emphasis.

From an implementation standpoint, translate mode will typically use a prompt pattern like:

System prompt: "You are an assistant that helps translate messages for specific audiences."\ Instruction: "Please translate/reframe the following message for [PersonaName], who is a [persona role and traits]. The output should be in [PersonaLanguage] and communicated in a style appropriate for this persona."\ Original message: "...(the content)...".

We will fine-tune the exact prompt for optimal results. The LLM will then produce the rewritten message.

2. Respond as Persona (Persona as Speaker)

In this mode, the service enables clients to ask a question or present a scenario, and get an answer as if the persona itself is responding. Here, the persona serves as the speaker or responder. This effectively lets the LLM role-play as the persona, using the persona's knowledge and communication style to generate an answer or commentary.

Example: Using the same ransomware scenario:\ - If we ask "How should we handle this incident?" and choose the CISO persona, the Respond as Persona mode would yield an answer that a typical CISO might give. In Portuguese (since that persona's language is pt-PT), it might say: "Como CISO, minha recomendação é primeiro isolarmos os sistemas afetados pelo ransomware, em seguida ..." and go on to detail technical incident response steps, perhaps referencing security teams, forensics, etc. The answer would be detailed and action-oriented from a security standpoint.\ - If we instead ask the Board Executive persona the same question, the response might come as a formal statement in English, like: "From a board perspective, I would want to ensure that our response team is containing the incident and that we have engaged cybersecurity experts. Our priority is to minimize financial and reputational impact...". This answer would be less technical, more strategic, and may include a request for frequent updates or assurance that stakeholders (investors, regulators) are kept informed -- reflecting a board-level concern.

This Respond as Persona capability can be used to simulate conversations with different roles. It's akin to having an expert or stakeholder "speak" via the LLM. For instance, a development team could ask "What would the CFO think about investing in this new security software?" and get a plausible answer crafted in a CFO-like tone. It's a powerful way to anticipate questions or viewpoints from various personas. It also overlaps with the concept of persona-based chatbots (where the chatbot has a fixed persona).

The prompt structure for this mode will be something like:

System prompt: "You are impersonating [PersonaName] -- [PersonaDescription]. Answer user queries as this persona."\ User prompt: "\<the user's question or statement>" (which might include scenario details).

The LLM then produces the persona's answer. We will ensure the prompt includes all relevant persona info so that the model stays in character (e.g. using first person if appropriate: "I, as [role], think that..." or simply a knowledgeable tone).

Chaining Both Modes (Double Translation Workflow)

It's worth noting that these two modes can be combined in sequence for optimal communication loops. For example, one could first use Translate-to-Persona to tailor a message for a persona, then use Respond-as-Persona by feeding that translated message to get the persona's hypothetical reply. This two-step exchange ensures that the persona fully "understands" the initial message as it was intended.

In fact, a suggested best practice is:\ - Take an important piece of information, translate it to the target persona's framing, then - Immediately have the persona respond (perhaps asking clarifying questions or acknowledging).

If the persona's response seems off or indicates misunderstanding, it's a signal that the translation might need adjustment. Ideally, though, by using the persona's own terminology and context in the first step, the persona (in the second step) will easily comprehend and respond appropriately. This loop can improve clarity of communication across knowledge domains.

Architecture and Integration

The Personas Service will be implemented as a lightweight web service (e.g., a Python FastAPI or Node.js Express service, given our stack preferences) that exposes RESTful endpoints or an API for the above functionalities. Key architectural considerations:

Usage Example Walk-through

To illustrate how everything comes together, let's walk through a realistic usage scenario step by step:

Scenario: There has been a security incident (ransomware attack) at a company. The technical incident report is written in a very IT-focused way. We need to communicate this to two stakeholders: Alice (the CISO of a subsidiary, who speaks Portuguese and is very technical) and Bob (a board member/CFO, who is English-speaking and non-technical). We'll use the Personas Service to generate the communications.

  1. Defining Personas: Suppose we have pre-defined persona profiles for Alice and Bob. Alice's persona (ID persona_ciso_pt) and Bob's persona (ID persona_board_exec_en) are stored in our system or available as JSON. If not already defined, we could create them via the service:

  2. We call POST /persona with Alice's details (as per earlier example JSON). Similarly for Bob. The service either stores them or returns an ID for immediate use. (If the service is truly stateless and not storing, we skip this step and just prepare the JSON in our client.)

  3. Translating the Incident Report: The original incident report text might be: "Division X experienced a ransomware attack compromising several servers. The attack has impacted the P&L --- financial reporting for Q4 might be delayed. Technical teams are working to contain the malware and restore backups."

  4. To generate Alice's version, we call POST /translate with persona_id = persona_ciso_pt (or the full persona JSON for Alice) and the above text.

  5. The Personas Service fetches Alice's persona definition (if given by ID), then creates a prompt for the LLM: "Translate the following for [Alice's persona details]" + original text.

  6. The LLM returns a Portuguese response, perhaps: "A Divisão X sofreu um ataque de ransomware que comprometeu vários servidores. Este ataque afetou os resultados (lucros e perdas) --- pode haver um atraso nos relatórios financeiros do Q4. As equipas técnicas estão a trabalhar para conter o malware e restaurar os backups."

    • Notice it kept the word ransomware (no need to explain to Alice), but it translated P&L to a phrase "resultados (lucros e perdas)" to clarify for a Portuguese reader. It's detailed yet in a professional tone.

  7. For Bob's version, we call POST /translate with persona_id = persona_board_exec_en and the same original text.

  8. The LLM might return an English output aimed at an executive: "Division X has suffered a ransomware cyber-attack affecting several servers. This has impacted our operations and potentially the Q4 profit-and-loss statements. Our IT team is actively containing the attack and working to restore data from backups. We will likely experience some downtime, but mitigation efforts are underway to protect financial reporting."

    • In Bob's version, jargon like "ransomware" is briefly framed as "cyber-attack," and the significance (impact on operations and reporting) is highlighted. It's written in a slightly more explanatory and reassured tone for an executive audience.

  9. Review and Send: The translated messages for Alice and Bob can now be sent to them. Each will receive a communication that is immediately understandable and relevant to their perspective. Alice gets the info in her language with technical details; Bob gets a high-level English briefing with business context.

  10. Optional -- Persona Response: Suppose we want to know how Alice (the CISO) might respond or what questions she might have. We can take the message we sent her and ask the service to respond as Alice.

  11. Call POST /respond with persona_id = persona_ciso_pt and input: "\<The translated message we gave Alice> \n\n What is your response or what actions will you take?" (or simply assume she read it and ask the persona for comments).

  12. The service will have the LLM role-play Alice. The output might be a response in Portuguese like: "Obrigado pelo aviso. Vou assegurar-me de que a nossa equipa de segurança em Portugal está pronta para ajudar e que revisamos imediatamente os nossos sistemas em busca de sinais semelhantes de ataque. Por favor, mantenha-me atualizado sobre o progresso e qualquer impacto financeiro confirmado."

  13. This shows the persona (Alice) acknowledging the info and outlining steps (ensuring her team is on alert, requesting updates on impact). This kind of simulation can be useful to anticipate needs or follow-ups from that persona.

  14. Lifecycle: After usage, since the service is stateless, it doesn't retain anything about this interaction. If another incident occurs, the same steps can be repeated. New personas can be added at any time by defining new JSON profiles and using them in requests. The existing LLM backend can be scaled as usage grows, and because each request is independent, we can easily distribute load.

Considerations and Future Enhancements

Conclusion

The Personas Service will fill a valuable role in making communication across diverse stakeholders more efficient and tailored. By harnessing LLM capabilities in a stateless microservice, we enable on-demand personalization of messages -- whether it's simplifying technical jargon for executives or adding technical depth for experts, and switching languages or tones as needed. Persona-driven communication has been shown to increase engagement and clarity, as the messaging is aligned with the audience's expectations[2]. Our service will provide a programmatic way to achieve this alignment.

In summary, the Personas Service allows any application or workflow to "speak the language" of its target personas, without manual re-writing for each audience. It uses the power of large language models to do the heavy lifting of translation and rephrasing, following persona profiles that capture the essence of who the audience or speaker is. This not only saves time but ensures consistency and appropriateness of communications across an organization. By keeping the service stateless and leveraging existing LLM infrastructure, we also ensure that it is scalable, maintainable, and easy to integrate into our ecosystem (e.g., hooking into incident response tools, report generators, chat interfaces, etc.).

Going forward, developers and LLM engineers working on this service should focus on robust prompt engineering, thorough testing with different personas, and a simple API design for ease of use. With those in place, personas.prod.mgraph.ai will become a key component for persona-aware AI interactions within our platform, enabling more effective and nuanced communication powered by AI.

[1] Building LLM-Powered Microservices With Kubernetes on AWS

https://dzone.com/articles/reliable-llm-microservices-kubernetes-aws

[2] LLM Personas Prompting Makes Personalized AI Simple

https://vidpros.com/llm-personas-prompting/

Released under CC BY 4.0. First published on docs.diniscruz.ai; this page as markdown.

← Surrogate Dependencies: Simulating Backends for Offline-First DevelopmentLLM Workflows/Stateflow Service - Technical Brief →