Exec summary: the term AI Persona is becoming a liability - we would like to align with the industry and rename to AI Agent
The term “AI Persona” was adopted by me in Discourse back in November 2023.
In AI terms, it feels like decades ago.
Over the past year and a half, a new trend has emerged in the AI space.
The words “agentic” and “AI Agents” are now used ubiquitously to describe AIs that act on our behalf (more technically, LLM Loop + Tools).
Discourse has supported AI agents since 2023; the key concept of calling an LLM → calling tools → calling an LLM and so on was baked into Discourse AI back then.
This year, we have made strides to centralize all of our AI LLM uses to funnel through personas. Our goal is to have one flexible primitive for working with any LLM and integrating into Discourse and third parties via tools.
By centralizing the logic, we also allow better flexibility for admins, since they can customize any persona.
Back on track.
The term “persona” has now become unique (in a bad way) and confusing in the ecosystem. Explaining to new Discourse admins that it supports agents is something that conveys the story in one sentence. Telling them we have “personas” creates a whole new conversation — which reaches the final point of “oh, you mean Discourse supports AI agents?”
Given that the industry has now decided on the term that is meant to be used, I think it would be healthy for Discourse to rename the primitive. It is a big change, and a lot of code and documentation will need to be amended to make it happen.
I am curious to know what various users of Discourse AI think about the rename and would like to take feedback.
An AI persona has very bad sound. And at same time when common atmosphere is turning more negative against AI use, because of various reasons, calling AI as a person will turn against Discourse at some point.
Outside this bubble I’ve used term a model, even that is different thing. But an agent is good. And more commonly used than a persona, I reckon.
The first question that comes to mind is whether there’s truly just one entity that needs naming. In my daily work with these systems, I use several distinct and related terms:
tool
client
server
host
ChatBot
MCP
connection
system prompt
user prompt
While I frequently encounter the words agent or agentic in documentation, I tend to avoid them in practice. Many users have conflicting interpretations of what these terms mean, which often creates more confusion than clarity.
Given the complexity often encountered with learning code architectures, I’ve found it helpful to ask LLMs like Claude to create wireframe diagrams in SVG format, often linking to relevant GitHub repositories. This approach could be particularly valuable for the multiple components mentioned in your original post.
Your mention of LLM Loop + Tools brings to mind Host with MCP Client + MCP Servers, illustrated here:
Please correct or expand on LLM Loop + Tools as needed if my analogy is flawed, as this seems central to identifying which specific entities need renaming.
The pace and breadth of Discourse’s AI integration work has been remarkable. The entire team should be proud of these accomplishments.
To me this is the most compelling reason to just hold tight and wait for a bit for more dust to settle.
I still feel persona is not quite a right fit, but the risk here is going through a 2000 lines of code rename just to need to repeat it again in a year when new terminology pops up.
Ideally, we can rename this in the settings. I like Persona because it’s easy to remember for users, and agents can be more accurate since they can have tool calls, making them more agentic. But I think, ideally, we could rename them to fit our community’s needs.
Now there is ChatGPT Agent. Since many who use ChatGPT really don’t need to or want to understand the AI and how it works, they will use the name Agent from this to pivot and add more definitions for agent.
Anthropic created sub-agents for use with Claude Code.
Custom sub agents in Claude Code are specialized AI assistants that can be invoked to handle specific types of tasks. They enable more efficient problem-solving by providing task-specific configurations with customized system prompts, tools and a separate context window.
이 변경 사항은 꽤 많은 번역에도 영향을 미칩니다. 번역가들이 가장 효율적으로 진행할 수 있는 방법은 무엇일까요?
“scheme”에서 “palette”로 전환할 때, 번역 메모리가 대부분의 경우 이전 텍스트를 제안했지만, 여전히 매번 "scheme"를 “palette”로 수동으로 교체해야 했으며, 개발자가 아마도 검색 및 치환을 사용했고 각 경우에 적절한지 빠르게 확인하거나, 하나를 건너뛰고 수동으로 변경해야 하는지 확인했을 것이라 생각하며 그 사람을 부러워했습니다.
여기에는 80개 이상의 텍스트가 있는 것 같아, 더 효율적인 방법이 있는지 물어볼 가치가 있다고 생각했습니다.
