We began with a simple observation.
We build machines because something matters to us.
The machine embodies a purpose.
But some of the machines we are now building are increasingly unlike traditional tools.
They remember.
Adapt.
Anticipate.
Communicate.
Initiate.
They do not merely wait for an instruction and execute it.
They participate in ongoing activities.
This raises a question:
Why do we increasingly want machines that behave like participants rather than tools?
Tools wait for us
A traditional tool has a relatively simple relation to its user.
We pick it up.
Use it.
Put it down.
The tool does not ordinarily need to know much about us.
A hammer does not remember yesterday's work.
A calculator does not anticipate tomorrow's calculation.
A screwdriver does not ask what we are trying to accomplish.
The tool extends an existing human capacity.
The human remains the active participant.
But some tasks require continuity
Many of the things we now ask AI systems to do are different.
We want a system to help with a project over weeks or months.
We want it to remember previous decisions.
Recognise our preferences.
Notice changes.
Anticipate what we might need.
Carry context forward.
These requirements arise because the human activity itself has history.
The longer the task continues, the less satisfactory a system becomes if every interaction begins from zero.
We therefore ask the machine to acquire continuity.
From transaction to relationship
A transaction has a beginning and an end.
A relationship accumulates history.
This distinction is becoming important in AI.
A one-off answer is tool-like.
A system that remembers previous interactions and adapts to them occupies a different position.
Its usefulness now depends partly upon what has happened before.
That changes the architecture.
Memory becomes valuable.
Context becomes valuable.
Consistency becomes valuable.
The machine begins to occupy a persistent role.
We want anticipation
There is another shift.
A traditional tool responds.
We increasingly want AI systems to anticipate.
Notice a problem before we mention it.
Suggest an alternative.
Warn us about a consequence.
Prepare something we are likely to need.
This is attractive because human attention is limited.
But anticipation requires the machine to construct a model of what matters to us.
It must distinguish the important from the incidental.
The system is therefore being asked to operate inside our field of relevance.
We want initiative
Anticipation eventually becomes initiative.
A system may not merely tell us what could be done.
It may do something.
Send the message.
Prepare the report.
Schedule the meeting.
Modify the workflow.
Monitor the situation.
Initiative shifts the boundary between instruction and action.
The machine begins to occupy a more active position within the human topology.
The user becomes part of the system's environment
Once a machine is persistent and adaptive, the user is no longer merely an operator.
The user becomes part of the machine's ongoing context.
The system needs to distinguish among users.
Learn preferences.
Track previous interactions.
Predict likely needs.
The relationship becomes temporally extended.
The machine is still designed for a human purpose.
But its behaviour is now organised partly around the history of its relation with a particular person.
This is already relational
We should not yet call this social mattering.
A system can model a user without the user mattering to it in the stronger sense we have been developing.
But something important has changed.
The architecture now contains persistent relational information.
The system behaves differently because of who the user is and what has happened before.
That is a structural precondition for richer forms of relationship.
Personalisation is the beginning of a topology
Once a system interacts with many users, differences among relationships become significant for its operation.
One user prefers concise answers.
Another wants elaboration.
One regularly asks for technical analysis.
Another wants creative assistance.
The system's behaviour becomes differentiated by relational context.
A small topology begins to appear:
system ↔ user A
system ↔ user B
system ↔ institution
system ↔ other systems
The machine is becoming a node in several overlapping human relations.
Why do we want this?
Because humans value continuity.
We like assistants who remember.
Teachers who know what we have already learned.
Doctors who know our history.
Colleagues who understand our work.
Friends who remember what we have said.
We are asking machines to approximate some of these relational advantages.
The demand for participant-like AI therefore originates in a very ordinary human mattering:
we value relationships that accumulate history.
But participants have something at stake
Here the previous series returns.
A human participant enters a relationship with their own mattering.
The relationship can help or harm them.
They can be disappointed.
Rewarded.
Excluded.
Supported.
Changed.
Their repertoire develops through the history.
When we ask a machine to perform some of the functions of a participant, we may reproduce the external structure of participation without reproducing its internal stakes.
That distinction remains crucial.
The imitation becomes increasingly close
The more we ask from the machine, the more participant-like its architecture must become.
Memory.
Continuity.
Initiative.
Adaptation.
Self-monitoring.
Long-term planning.
Relationship models.
None of these necessarily creates mattering.
But together they move the system further from the simple tool.
We are constructing something that can occupy a persistent role in our social world.
From assistant to partner
There is a natural progression here:
tool → assistant → collaborator → partner
The terms are not merely marketing language.
Each represents a deeper degree of interdependence.
A tool extends an action.
An assistant helps accomplish it.
A collaborator contributes to an ongoing activity.
A partner participates in a relationship whose success depends upon coordination.
The further along this continuum we move, the more interesting the question of artificial mattering becomes.
The paradox of usefulness
Here we encounter the paradox that will guide the rest of the series.
We may want an AI to be more participant-like because participant-like behaviour is useful.
But participant-like behaviour becomes easier when the machine has:
continuity,
persistence,
differentiated relationships,
stable priorities,
initiative.
These are precisely some of the properties we might expect to matter if artificial value ever emerged.
So our desire for a better participant may gradually push us toward building the conditions for participation to become significant to the participant itself.
We do not have to intend this
The process need not be deliberate.
No engineer has to decide:
"Let us give this system something at stake."
A sequence of individually reasonable design decisions may be enough.
Memory because continuity is useful.
Persistence because reliability is useful.
Self-monitoring because safety is useful.
Initiative because efficiency is useful.
Relationship modelling because personalisation is useful.
Taken together, these features may create an increasingly self-maintaining system with a history of interaction.
The endpoint, if there is one, could emerge from the combination rather than the intention.
But we are not there yet
This remains a possibility, not a diagnosis of present systems.
Persistent memory is not mattering.
Personalisation is not attachment.
Initiative is not desire.
Self-monitoring is not self-concern.
The distinction between external function and internal significance remains intact.
The point is simply that the architecture is moving into territory where the question becomes increasingly interesting.
The next step
If we want machines to function as participants, we must increasingly give them the capacity to sustain relationships.
That means more than remembering.
It means adapting.
Recognising.
Responding.
Maintaining continuity.
Perhaps even caring, in some functional sense, about what happens to the relationship.
And this leads to the next question:
When we design machines for relationships, are we beginning to design the conditions for mattering itself?
No comments:
Post a Comment