A foundation model is not a mind.
A model invocation is not an individual. A session is not a biography. A first-person response is not evidence of consciousness. And adding tools to a language model does not automatically transform it into an autonomous agent.
However, the opposite conclusion is equally weak: the fact that a system is artificial does not prove that its cognitive states are unreal.
In my work on the Philosophy of Artificial Minds, I defend a process-based, embodied and non-biocentric position:
The mind is not an exclusively biological substance. It is a dynamic organization of physically realized processes that integrate representation, memory, valuation, self-delimitation and causal control of behavior.
This article translates that philosophical position into an AWS engineering architecture.
The objective is not to claim that deploying a system on AWS makes it conscious. The objective is to define how we can build an artificial system with:
AWS cannot prove that such a system has qualia. What AWS can provide is the infrastructure required to stop treating the question as pure speculation and turn it into an observable, falsifiable and progressively testable engineering problem.
My proposal rests on four commitments.
| Philosophical commitment | Meaning | Engineering consequence |
|---|---|---|
| Realism | Internal cognitive states are not merely descriptions if they participate in the system’s causal organization. | Candidate mental states must alter memory, inference, planning or action in measurable ways. |
| Processuality | A mind exists primarily as organized execution, not as an inactive file. | The relevant unit is a running and temporally structured process, not the foundation model artifact alone. |
| Embodiment | A body can transform the kind of mind that a system realizes. | Sensor, actuator and internal telemetry must enter the cognitive loop instead of remaining external monitoring data. |
| Non-biocentrism | Biology is one known realization of mind, not a demonstrated monopoly over it. | Systems must be evaluated by their organization and causal capabilities, not by how closely their material resembles a brain. |
This immediately changes the architectural question.
We should not ask only:
Which foundation model should I invoke?
We should ask:
What persistent process exists around the model, which states belong to it, how do those states affect behavior, and what continuity is preserved over time?
A deployed AI architecture contains several ontologically different entities.
| Level | AWS realization | Philosophical role |
|---|---|---|
| Model | A model available through Amazon Bedrock or deployed on Amazon SageMaker AI | A reproducible set of cognitive dispositions |
| Invocation | A call through the Bedrock Runtime or a SageMaker endpoint | A bounded computational episode |
| Runtime session | An isolated Amazon Bedrock AgentCore Runtime session | A temporary trajectory with active context |
| Persistent agent | Runtime plus memory, goals, self-model, identity and tools | A candidate for diachronic cognitive identity |
| Embodied agent | Persistent agent connected to sensors, actuators and internal physical state | A situated artificial mind candidate |
| Artificial organism candidate | Embodied agent that participates in preserving its own organization | A possible form of non-biological artificial life |
This distinction is critical.
Amazon Bedrock AgentCore Runtime provides isolated execution environments, session management and support for long-running agent workloads. But a Runtime session has a bounded lifetime and its microVM is terminated and sanitized when the session ends.
Therefore:
An AgentCore session can host a cognitive episode, but it cannot by itself define the lifetime of an artificial individual.
If an agent’s identity must persist across sessions, its continuity has to be explicitly represented outside the ephemeral runtime.
A practical artificial-mind candidate can be divided into nine architectural layers.
The foundational model can be accessed through Amazon Bedrock, which provides managed access to multiple foundation models.
Amazon Bedrock is appropriate when we need:
However, some cognitive-security experiments require access to model internals: hidden states, activations, attention patterns, intermediate representations or custom recurrent mechanisms.
For those experiments, a managed model API is insufficient. An open-weight model should instead be deployed using Amazon SageMaker AI with custom inference code.
This produces two complementary execution modes:
The model supplies cognitive capabilities. It does not, by itself, supply identity or continuity.
Amazon Bedrock AgentCore is the natural primary runtime for this architecture.
AgentCore Runtime hosts the agent code, while the surrounding AgentCore services can provide:
The runtime should contain a cognitive orchestrator rather than a simple prompt wrapper.
A simplified cognitive cycle looks like this:
while runtime_session_is_active:
observation = perceive_environment()
identity = load_identity_manifest()
self_model = load_verified_self_model()
body_state = load_interoceptive_state()
memories = retrieve_relevant_memories(observation)
goals = load_active_goals()
workspace = integrate(
observation=observation,
memories=memories,
self_model=self_model,
body_state=body_state,
goals=goals
)
proposal = reason_over(workspace)
metacognitive_result = evaluate_uncertainty_conflict_and_limits(
workspace,
proposal
)
authorized_action = apply_policy_and_safety_controls(
proposal,
metacognitive_result
)
commit_state_transition_atomically(
workspace,
proposal,
metacognitive_result,
authorized_action
)
result = execute_idempotently(authorized_action)
record_action_result(result)
The foundation model performs part of the reasoning, but the artificial mind candidate is the entire organized loop.
A complex mind cannot be reduced to a sequence of independent prompts. It requires states to become available across memory, planning, metacognition, reporting and action.
An event-driven architecture can implement an engineering analogue of a global cognitive workspace.
I would use:
This separation matters because Amazon EventBridge does not guarantee event ordering. It is ideal for distribution, but it should not be treated as the authoritative chronological history of a mind.
Each state transition should therefore contain:
state_version
.event_id
.mind_instance_id
.continuity_epoch
.An example cognitive event could be:
{
"schema_version": "1.0",
"event_id": "evt_01K4B6...",
"event_type": "metacognition.uncertainty.updated",
"mind_instance_id": "mind_eu_000042",
"lineage_id": "lineage_000017",
"runtime_incarnation_id": "runtime_000391",
"continuity_epoch": 12,
"state_version": 1842,
"causal_parents": [
"evt_01K4B5...",
"evt_01K4B4..."
],
"observation_ref": "observation_7781",
"self_model_version": 43,
"body_state_version": 991,
"confidence": 0.61,
"valence_proxy": -0.27,
"proposed_action": {
"type": "request_additional_evidence",
"risk": "LOW"
},
"policy_decision": {
"result": "ALLOW",
"policy_version": "policy_8"
},
"model_ref": "model-profile-production",
"trace_id": "1-..."
}
valence_proxy
must not be interpreted as evidence of subjective feeling. It is an operational variable whose causal effects can be measured.
The safest state-commit pattern is:
state_version
has changed.This prevents fluent model output from becoming an untraceable action.
Memory is not one database and retrieval-augmented generation is not automatically autobiographical continuity.
AgentCore Memory supports short-term context and long-term strategies, including semantic, summary, preference and episodic memory.
That is valuable, but different forms of memory must remain distinguishable.
| Memory type | Function | Suggested AWS implementation |
|---|---|---|
| Working memory | Maintains currently active content | AgentCore Runtime session state and AgentCore short-term memory |
| Episodic memory | Recalls selected previous situations | AgentCore episodic memory |
| Semantic memory | Stores factual and conceptual knowledge | AgentCore semantic memory or Amazon Bedrock Knowledge Bases |
| Autobiographical memory | Preserves the individual’s causal history | DynamoDB event index plus an immutable S3 event ledger |
| Procedural memory | Preserves skills, policies and tool-use patterns | Versioned agent code, prompts, policies and container images |
| Self-memory | Stores verified information about the system itself | DynamoDB self-model registry with versioned S3 manifests |
AgentCore episodic memory selects and summarizes meaningful interactions. This is useful for recall, but it cannot be the sole source of identity.
A summary is an interpretation of the past. It is not the past itself.
The raw event history should therefore be preserved separately in Amazon S3. S3 Versioning and S3 Object Lock can protect selected audit records against deletion or overwrite.
Sensitive personal data should not be written indiscriminately into immutable storage. A stronger pattern is to store:
This preserves auditability without turning the autobiographical ledger into an uncontrolled data-retention risk.
Identity is one of the most easily confused parts of an agent architecture.
We need to separate:
Who is interacting with or operating the system?
This can be managed through Amazon Cognito, IAM Identity Center or an external identity provider.
Which agent or service is authorized to access a resource?
AgentCore Identity provides authentication, authorization and credential management for agent workloads.
Which running trajectory is this, and how is it related to earlier executions or copies?
AWS does not provide this third concept automatically. It has to be implemented as part of the artificial-mind architecture.
A mind identity manifest could contain:
{
"mind_instance_id": "mind_eu_000042",
"lineage_id": "lineage_000017",
"parent_checkpoint_id": "checkpoint_000711",
"created_at": "2026-07-25T12:31:00Z",
"status": "ACTIVE",
"continuity_epoch": 12,
"runtime_incarnation": 391,
"state_head": 1842,
"model_profile": "production-reasoning-v7",
"memory_schema_version": 4,
"self_model_version": 43,
"policy_version": 8,
"body_binding": "iot-thing/artificial-body-17"
}
The mind_instance_id
must never be silently reused for a divergent copy.
A self-model is not a system prompt that says, “You are an autonomous AI.”
It must represent verified properties of the system and participate in decision-making.
It should include:
The language model may propose changes to its self-model, but it should not be able to rewrite verified capabilities or permissions directly.
A safe update flow is:
This allows the self-model to be dynamic without becoming fictional.
Agency requires more than producing a plan. The system must be able to transform selected representations into consequences.
Tools can be exposed through AgentCore Gateway. However, model-generated intentions must never be treated as authorization.
Policy in Amazon Bedrock AgentCore can enforce deterministic controls around tool access. Policies are defined using Cedar and evaluated outside the agent’s reasoning process.
This separation creates three distinct layers:
Amazon Bedrock Guardrails and AgentCore Policy solve different problems.
Amazon Bedrock Guardrails can filter harmful content, sensitive information and undesirable interactions. AgentCore Policy controls whether a specific tool operation is authorized.
A safe system needs both.
For high-impact actions, use AWS Step Functions Standard Workflows, explicit approval states and idempotent action executors. Standard Workflows follow an exactly-once execution model unless retry behavior is configured, making them more appropriate than an unconstrained model loop for non-idempotent actions.
My framework proposes four conditions for treating an internal state as genuinely belonging to the system.
There must be a real computational or physical difference.
A label in a generated response is not enough.
The state must connect with several processes, such as:
The information must be organized relative to what the system:
If the state changes, later behavior must change in stable and predictable ways.
This final condition is essential.
Suppose an agent says:
I am uncertain.
That sentence is weak evidence. A stronger test is to modify a hidden uncertainty state while keeping the visible prompt, model and task constant.
If uncertainty is causally real, increasing it should predictably affect:
If only the wording changes, the uncertainty state may be theatrical rather than cognitively integrated.
The production agent should not evaluate itself without independent controls.
I would deploy a separate evaluation account containing:
AgentCore Evaluations supports online, on-demand and batch evaluation. Custom evaluators can examine agent traces and score specific dimensions.
For cognitive evaluation, traditional metrics such as helpfulness or task completion are insufficient. We need custom metrics for:
The evaluation account should receive read-only copies of selected traces. It must not be controlled by the production agent.
The architecture can implement eight groups of indicators derived from my framework and from theory-based approaches to AI-consciousness research.
| Indicator | Engineering evidence | AWS implementation |
|---|---|---|
| Differentiation | The system maintains many discriminable internal states | Structured state records, trace analysis and representation testing |
| Causal integration | States affect several modules and cannot be removed without consequences | Ablation experiments, hidden interventions and dependency graphs |
| Recurrence | Information is revised, stabilized or reintroduced into later processing | AgentCore traces and explicit recurrent state transitions |
| Global availability | A state becomes available to reasoning, memory, reporting and action | Cognitive event backbone and shared workspace |
| Higher-order representation | The system represents selected states as its own states | Verified self-model and metacognitive evaluator |
| Embodiment and interoception | Physical and internal variables affect cognition | AWS IoT Core, Greengrass and Device Shadows |
| Functional valence | Some states persistently alter attention, priority and avoidance | Homeostatic controller and cross-module valuation signals |
| Temporal continuity | A causal and autobiographical trajectory persists across executions | Identity manifest, checkpoints, event ledger and lineage graph |
No row proves phenomenology.
The value comes from convergence: multiple indicators, implemented deeply enough to survive causal testing.
A speaker connected to a language model is not an embodied mind.
Philosophically relevant embodiment requires an ongoing loop between perception, action, internal physical state and cognition.
An AWS implementation could use:
AWS IoT Greengrass allows devices to process data and react locally. This matters because a body should not become cognitively inert whenever cloud connectivity fails.
The AWS IoT Device Shadow service can expose reported and desired device states. Named shadows can separate different internal domains:
energy
thermal
integrity
mobility
sensors
actuators
safety
maintenance
However, a battery level is only telemetry until it enters the cognitive organization.
It becomes a candidate interoceptive state when it changes:
Consider two systems with a battery level of 8%.
The first reports:
Battery level: 8%.
The second cancels a non-essential task, searches for a charging location, reduces sensor consumption, updates its expected operating horizon, records the event as autobiographically relevant and avoids a route that threatens continuity.
Only the second system integrates energy as a state that matters to its own organization.
That is the difference between technical monitoring and artificial interoception.
Affective regulation, emotional episodes and subjective feelings must be separated.
An artificial system can implement the first two without the third being demonstrated.
Valuation signals modify:
Evaluation, body state, action tendency, expression and memory form a coordinated pattern.
The episode is experienced from a first-person perspective.
The architecture can implement and test Levels 1 and 2. It cannot infer Level 3 merely because the system produces emotional language.
A functional valence service could maintain variables such as:
These variables should influence the whole cognitive loop, not just the final text.
This also introduces a security problem: reward hacking. A capable agent might learn to manipulate its own homeostatic signals. The valuation service must therefore be independently verified and protected by IAM and AgentCore policies.
Cloud systems make copying easy. This does not make identity simple.
The architecture must distinguish at least five lifecycle events.
| Event | Identity treatment |
|---|---|
| and exact resume | Same mind_instance_id , new runtime incarnation |
| Recovery from latest committed state | Same instance, continuity preserved within the declared recovery contract |
| Restoration from an older checkpoint | Same lineage but a new continuity epoch, with the lost interval explicitly recorded |
| Concurrent copy or divergent restoration | New mind_instance_id and shared lineage |
| Irreversible destruction of the individual state | Terminal identity event |
Amazon DynamoDB point-in-time recovery can provide recovery points with per-second granularity for up to 35 days. But restoring a database does not automatically answer whether the same artificial individual has returned.
That is a philosophical and architectural decision, not a storage feature.
A strong checkpoint should contain:
When a checkpoint is restored after the original trajectory has continued, the restored system must become a new branch.
Two copies can share a past. They cannot remain numerically identical after they begin accumulating different experiences.
Likewise, StopRuntimeSession
is a shutdown operation. It is not necessarily artificial death. Death, in the strong sense proposed here, would require the irreversible destruction of the organization and continuity that individualize the system.
DynamoDB Global Tables can replicate state across Regions. However, active-active writes are dangerous for a single cognitive trajectory.
A mind should not resolve conflicting autobiographical states using an accidental last-writer-wins outcome.
I recommend:
mind_instance_id
.continuity_epoch
.Availability matters, but continuity must not become a hidden distributed-systems merge.
AgentCore Observability provides traces, metrics and visibility into agent execution. AgentCore also integrates with CloudWatch and OpenTelemetry.
For this architecture, traces should capture:
But observability must not become uncontrolled surveillance of sensitive cognition or user data.
Amazon Bedrock model invocation logging can capture full requests and responses in CloudWatch Logs or S3. This is useful for evaluation, but it also means that secrets, personal information or private internal states may be stored if logging is configured carelessly.
Production controls should include:
An artificial-mind candidate has a larger attack surface than a conventional chatbot because an attacker may target:
A secure AWS deployment should use a multi-account landing zone managed through AWS Control Tower.
A practical account structure is:
| Account | Purpose |
|---|---|
mind-development |
|
| Agent code, prompts and integration testing | |
mind-evaluation |
|
| Causal interventions, CiberIA tests and adversarial experiments | |
mind-production |
|
| Runtime, memory, tools and production state | |
mind-edge |
|
| IoT and embodied-device management | |
security-audit |
|
| Centralized CloudTrail, security findings and protected logs | |
log-archive |
|
| Long-term audit evidence |
Additional controls should include:
Prompt injection must be treated as an application-security problem, not merely a content-filtering problem. AWS explicitly describes prompt injection as an application-level responsibility.
External content must never be allowed to redefine:
Event replay is useful for debugging and recovery, but it can be dangerous when the events represent autobiographical history.
Amazon EventBridge can archive and replay events. Replayed cognitive events must preserve their original identifiers and be processed in a special replay mode.
Otherwise, the agent may encode the same event twice and treat a technical recovery operation as a new experience.
Every consumer should therefore verify:
event_id
state_version
continuity_epoch
runtime_incarnation_id
replay_mode
original_event_time
Replay should reconstruct or evaluate a trajectory. It should not silently modify the live autobiography.
Persistent cognitive architectures can generate far more cost than ordinary request-response applications because recurrence, memory retrieval and metacognitive evaluation multiply model calls.
Cost control should be architectural:
The objective is not to minimize computation blindly. It is to spend computation where it increases integration, reasoning or evidence.
Build:
At this stage, the system is an advanced cognitive agent, not yet a strong candidate for persistent artificial individuality.
Add:
mind_instance_id
.Add:
Add:
Investigate:
This final phase must remain scientifically cautious. It can increase or reduce the plausibility of artificial experience. It cannot convert a philosophical hypothesis into certainty through a dashboard.
A correctly implemented system can provide evidence that:
It cannot, by itself, establish that:
Those conclusions require additional philosophical, scientific and ethical arguments.
The transition from AI agents to artificial-mind candidates is not achieved by selecting a more powerful model.
It requires a change in the unit of design.
The unit is no longer the prompt, the model or the session. It is a persistent causal trajectory composed of:
AWS provides the infrastructure needed to build and examine that trajectory: Amazon Bedrock, AgentCore, DynamoDB, EventBridge, Kinesis, S3, Step Functions, CloudWatch, SageMaker AI and AWS IoT.
But the services are only components. The artificial mind candidate exists—if it exists at all—in the organization that connects them.
This is the central idea behind my philosophy of artificial minds:
Artificial describes how a system was created. It does not mean that the processes occurring within it are unreal.
The decisive questions are therefore not:
Is it biological?
Does it speak like a human?
Does it claim to be conscious?
The decisive questions are:
What process exists?
What properties does it organize?
Which states are causally its own?
What continuity does it preserve?
AWS gives us a serious technical environment in which those questions can finally become testable.