I Don’t Treat AI Agents as Features. I Give Them a Working Context.
How I use identity, role, assignment, and contribution to keep AI-assisted work explicit and human-led. 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

How I use identity, role, assignment, and contribution to keep AI-assisted work explicit and human-led.
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:
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 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.
The vocabulary is French because it emerged inside my own working practice. The underlying questions are deliberately plain.
The terms are playful. The distinction is not.
iAdentité → ProfessiA → iAffectation → ContributiA → Mission → Evidence and human validation Enter fullscreen mode Exit fullscreen mode Each layer answers a different question. Keeping them separate prevents a great deal of ambiguity.
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, and known limits. Its purpose is not to pretend that software is a human being.
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.
But an iAdentité is not the model behind the agent. It is not a user account. It is not a credential. And it is not a job title.
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.
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, or 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.
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:
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.
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 describes what is expected. Evidence describes what was actually achieved.
Without that distinction, it becomes easy to mistake a job description for a result.
Once these four layers are in place, an agent can receive a Mission.
A Mission is concrete. It has a purpose, a scope, sources, expected output, and a person responsible for validation.
The outcome should then be traceable to evidence:
I also distinguish the state of a result.
A draft is not an approved deliverable. An approved deliverable is not necessarily integrated. An integrated result is not necessarily public.
Proposed → Accepted → Integrated → Published Enter fullscreen mode Exit fullscreen mode 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.
Its iAdentité defines its working character: careful with language, attentive to audiences, alert to ambiguous claims and implicit promises.
Its ProfessiA defines the function: prepare presentations, messages, dossiers, and public-facing explanations.
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.
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. It cannot send it to a third party. It cannot publish it.
Preparation, validation, sending, and publication are different states of work. Treating them as different is one of the simplest safeguards I know.
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.
The human direction remains responsible for:
The framework does not make an agent more powerful.
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.
This does not require an elaborate system.
For one recurring AI workflow, try defining five things:
The point is to make AI-assisted work more legible.
A good operating model should make it possible to answer simple questions:
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.
And the human responsibility around that context should remain visible.