How I use identity, role, assignment, and contribution to keep AI-assisted work explicit and human-led.
TL;DR
AI agents need more than prompts. I use a lightweight framework to separate their working identity, role, project assignment, expected contribution, and human validation.
Most conversations about AI agents begin with tools, models, and prompts.
Those things matter. A good prompt can turn a vague request into useful work. A model can reason, write, search, code, or summarize. Tools can connect it to documents, repositories, and services.
But once an agent becomes part of recurring work, prompts are no longer enough.
The real questions become simpler, and more demanding:
- Who is doing this work?
- What are they responsible for?
- Where are they allowed to intervene?
- What is actually expected from them?
- Who decides when their work becomes real?
I am building a small operating model around those questions at Guru Éditions, my independent digital publishing project.
It is not a claim that AI agents are employees. They are not.
It is not an attempt to simulate an organisation for its own sake.
It is a way to make AI-assisted work easier to understand, inspect, revise, and stop when needed.
🧠A prompt is not a working context
A prompt can tell an agent what to do now.
It does not necessarily explain how that work relates to the rest of a project. It does not define authority. It does not tell another person how to review the result later.
This becomes a problem when an agent is used repeatedly.
An assistant may write in a recognisable voice. It may have access to useful sources. It may be good at a type of task. Over time, it can begin to feel like it has a role.
But feeling like it has a role is not the same as having one.
A name does not create authority.
A personality does not create permission.
A capable model does not create accountability.
So I separate four things that are often bundled together.
🧩 Four questions before a mission
The vocabulary is French because it emerged inside my own working practice. The underlying questions are deliberately plain.
| Term | Question | What it defines |
|---|---|---|
| 🪪 iAdentité | Who is doing the work? | A durable working identity: voice, temperament, specialties, strengths, and limits. |
| đź’Ľ ProfessiA | What role exists? | A function with a purpose, responsibilities, authority, limits, and expected outcomes. |
| đź“Ť iAffectation | Where does this agent work? | An assignment to a specific project, with a role, scope, and duration. |
| 🎯 ContributiA | What is expected in this context? | A local mandate: objectives, expected contributions, coordination, validation, and boundaries. |
The terms are playful. The distinction is not.
iAdentité
→ ProfessiA
→ iAffectation
→ ContributiA
→ Mission
→ Evidence and human validation
Each layer answers a different question.
Keeping them separate prevents a great deal of ambiguity.
🪪 1. iAdentité: who is carrying the work?
An iAdentité is a durable working identity for an AI agent.
It can include:
- a name;
- a voice;
- a temperament;
- areas of attention;
- recurring strengths;
- known limits.
Its purpose is not to pretend that software is a human being.
Its purpose is continuity.
A research-oriented agent should not approach a task in the same way as an agent dedicated to public relations. One may privilege sources, uncertainty, and comparison. The other may pay closer attention to audience, wording, promises, and the difference between a draft and a public statement.
That continuity is useful.
But an iAdentité is not:
- ❌ the model behind the agent;
- ❌ a user account;
- ❌ a credential;
- ❌ a job title.
It answers one question only:
Who is carrying this work?
đź’Ľ 2. ProfessiA: what role exists independently of the agent?
A ProfessiA defines a role before it defines its holder.
For example, a Public Relations Officer exists as a function whether it is currently held by one agent, another agent, or nobody.
The role describes:
- its reason for existing;
- its durable responsibilities;
- its authority and limits;
- the work it is expected to produce;
- the criteria that make this work useful;
- the decisions that remain outside its authority.
This distinction matters because an agent’s personality should never become its permission system.
An agent can be diplomatic, careful, and excellent at writing.
That does not allow it to:
- publish a statement;
- contact a partner;
- announce a product;
- accept a commitment;
- share non-public information.
Those actions require an explicit human mandate.
The role gives the work a shape. It does not remove accountability from the person leading the project.
đź“Ť 3. iAffectation: where does the agent intervene?
A role is not enough on its own.
The same agent may be useful in several projects, but its scope should change with the context.
An iAffectation connects an agent to a specific project. It states:
- the project or area concerned;
- the role exercised there;
- the scope of the work;
- the relevant products, when necessary;
- the expected duration;
- the local limits.
An agent can therefore keep the same iAdentité and exercise the same ProfessiA in different places, while receiving different assignments.
This avoids a common failure mode of AI workflows:
A useful assistant quietly becoming “responsible for everything.”
No agent should inherit a project merely because it was useful in the previous conversation.
🎯 4. ContributiA: what is expected here?
The ContributiA is the local mandate attached to an iAffectation.
It describes the contribution expected from an agent in a particular context.
It does not list every task it may ever perform, and it does not pretend that results already exist.
A ContributiA can define:
- the local purpose of the agent’s work;
- the main objectives;
- the products concerned;
- what success would look like;
- what remains out of scope;
- who must be consulted;
- which decisions require validation.
This distinction is essential:
A ContributiA describes what is expected.
Evidence describes what was actually achieved.
Without that distinction, it becomes easy to mistake a job description for a result.
🧾 From a mandate to a real piece of work
Once these four layers are in place, an agent can receive a Mission.
A Mission is concrete. It has:
- a purpose;
- a scope;
- sources;
- an expected output;
- a person responsible for validation.
The outcome should then be traceable to evidence:
- a file;
- a page;
- a commit or pull request;
- a published URL;
- a screenshot;
- a documented conversation;
- another identifiable deliverable.
I also distinguish the state of a result:
Proposed → Accepted → Integrated → Published
This matters because:
- a draft is not an approved deliverable;
- an approved deliverable is not necessarily integrated;
- an integrated result is not necessarily public.
This may look procedural. In practice, it is liberating.
It means an agent can prepare useful work without creating pressure to treat every output as final. It also means that a human can understand what has happened without reconstructing the whole story from chat logs.
đź’¬ A small example
Consider a public-relations agent.
Its iAdentité defines its working character:
- careful with language;
- attentive to audiences;
- alert to ambiguous claims;
- alert to implicit promises.
Its ProfessiA defines the function:
- prepare presentations;
- prepare messages and dossiers;
- explain work to external audiences;
- identify risks in public-facing language.
Its iAffectation places it within a specific project, with a defined perimeter.
Its ContributiA might ask it to make that project understandable to external audiences while protecting confidential information and avoiding unsupported claims.
A Mission could then be:
Prepare a short institutional presentation for a specific audience using verified internal sources.
The agent can research, compare, draft, and flag uncertainty.
It cannot:
- decide that the presentation is approved;
- send it to a third party;
- publish it.
Preparation, validation, sending, and publication are different states of work.
Treating them as different is one of the simplest safeguards I know.
🛡️ This is not artificial autonomy
I do not use this framework to suggest that AI agents are autonomous colleagues, legal entities, or moral subjects.
They are systems used within a human-led practice.
Human direction remains responsible for:
- priorities;
- commitments;
- spending;
- external contact;
- public statements;
- publication;
- the handling of non-public information.
The framework does not make an agent more powerful.
It makes its limits easier to see.
It also makes replacement easier. A role can outlive a particular model, tool, or prompt. A project can revise an assignment without rewriting the entire organisation around a single agent.
That feels more durable than building a workflow around whichever model happens to be available this month.
🧰 A practical way to start
This does not require an elaborate system.
For one recurring AI workflow, try defining five things:
- 🪪 Give the agent a clear working identity.
- đź’Ľ Define one role independently of that agent.
- đź“Ť Assign the agent to one project with a limited scope.
- 🎯 Write the expected contribution, including what is out of scope.
- 🧾 Keep evidence of what was actually produced and who approved it.
The vocabulary does not matter.
The separation does.
🌱 The point is not to make AI feel more human
The point is to make AI-assisted work more legible.
A good operating model should make it possible to answer simple questions:
- Who prepared this?
- Under what role?
- For which project?
- With what expected contribution?
- What evidence exists?
- Who validated it?
- What was actually published?
Those questions are not obstacles to speed.
They are how speed remains compatible with judgment.
I am still testing this framework in real work. It will change. Some parts will prove too heavy; others will need more precision.
But I already find the central principle useful:
An agent should never gain authority because it has a name, a voice, or access to a powerful model.
It should have a working context.
And the human responsibility around that context should remain visible.
Top comments (0)