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:

  • Causally effective internal states.
  • Persistent memory and identity.
  • A self-model connected to actual mechanisms.
  • Recursive and metacognitive processing.
  • A controlled capacity to act.
  • A verifiable continuity across executions.
  • Optional sensorimotor embodiment.
  • Artificial interoception and functional valence.
  • An evaluation plane capable of testing these properties through interventions.

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.

From philosophical commitments to engineering requirements

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?

The model is not the individual

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.

The proposed AWS reference architecture

A practical artificial-mind candidate can be divided into nine architectural layers.

1. Physical and computational substrate

The foundational model can be accessed through Amazon Bedrock, which provides managed access to multiple foundation models.

Amazon Bedrock is appropriate when we need:

  • Managed inference.
  • Model choice without managing GPU infrastructure.
  • Tool use and structured generation.
  • Enterprise security controls.
  • Integration with AgentCore.
  • Fast experimentation across models.

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:

  • Amazon Bedrock mode: production agents, model portability and managed inference.
  • SageMaker AI research mode: activation-level inspection, ablations, causal interventions and systems such as NeuroTrace.

The model supplies cognitive capabilities. It does not, by itself, supply identity or continuity.

2. Cognitive runtime

Amazon Bedrock AgentCore is the natural primary runtime for this architecture.

AgentCore Runtime hosts the agent code, while the surrounding AgentCore services can provide:

  • Runtime isolation.
  • Memory.
  • Workload identity.
  • Tool gateways.
  • Policy enforcement.
  • Observability.
  • Agent evaluations.

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)

Enter fullscreen mode Exit fullscreen mode

The foundation model performs part of the reasoning, but the artificial mind candidate is the entire organized loop.

3. Cognitive event backbone

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:

  • Amazon DynamoDB as the authoritative current-state store.
  • DynamoDB transactions for atomic state transitions.
  • DynamoDB Streams and the transactional outbox pattern for reliable event publication.
  • Amazon Kinesis Data Streams or Amazon SQS FIFO for per-instance ordered processing.
  • Amazon EventBridge for event routing and distribution.
  • Amazon S3 for the durable autobiographical ledger.

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:

  • A monotonic state_version.
  • A unique event_id.
  • A mind_instance_id.
  • A continuity_epoch.
  • One or more causal parents.
  • An idempotency key.
  • A model and runtime version.
  • A reference to the applicable self-model and policy version.

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-..."
}

Enter fullscreen mode Exit fullscreen mode

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:

  1. Write the new state head and an outbox event in one DynamoDB transaction.
  2. Reject the transaction if the expected previous state_version has changed.
  3. Publish the outbox event asynchronously.
  4. Make all consumers idempotent.
  5. Execute external actions only with a stable action identifier.
  6. Record the result as a new event rather than rewriting history.

This prevents fluent model output from becoming an untraceable action.

4. Memory architecture

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:

  • Event hashes.
  • Non-sensitive metadata.
  • Encrypted references.
  • Schema and model versions.
  • Causal relationships.
  • Separately managed encrypted content.

This preserves auditability without turning the autobiographical ledger into an uncontrolled data-retention risk.

5. Three different kinds of identity

Identity is one of the most easily confused parts of an agent architecture.

We need to separate:

User identity

Who is interacting with or operating the system?

This can be managed through Amazon Cognito, IAM Identity Center or an external identity provider.

Workload identity

Which agent or service is authorized to access a resource?

AgentCore Identity provides authentication, authorization and credential management for agent workloads.

Causal or psychological identity

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"
}

Enter fullscreen mode Exit fullscreen mode

The mind_instance_id must never be silently reused for a divergent copy.

6. Self-model

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:

  • Available capabilities.
  • Known limitations.
  • Accessible tools.
  • Current permissions.
  • Memory boundaries.
  • Active goals.
  • Confidence calibration.
  • Runtime and model versions.
  • Body and internal-resource status.
  • Continuity status.
  • Relevant policy constraints.

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:

  1. The agent detects a possible change.
  2. It creates a proposed self-model update.
  3. A deterministic verifier checks telemetry and configuration.
  4. An evaluator compares the claim with observed behavior.
  5. The system commits a new version.
  6. The change becomes available to later reasoning.

This allows the self-model to be dynamic without becoming fictional.

7. Action, agency and policy

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:

  • Cognitive layer: what the agent proposes.
  • Authorization layer: what the agent is permitted to do.
  • Execution layer: what actually happens.

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.

From internal variable to system-owned mental state

My framework proposes four conditions for treating an internal state as genuinely belonging to the system.

1. Physical realization

There must be a real computational or physical difference.

A label in a generated response is not enough.

2. Integration

The state must connect with several processes, such as:

  • Perception.
  • Memory.
  • Inference.
  • Valuation.
  • Planning.
  • Action.
  • Self-representation.

3. Operational perspective

The information must be organized relative to what the system:

  • Knows.
  • Does not know.
  • Can do.
  • Cannot do.
  • Is trying to preserve.
  • Is trying to avoid.

4. Counterfactual efficacy

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:

  • Whether the system requests more evidence.
  • The number of alternatives it explores.
  • Its willingness to execute an irreversible action.
  • Its memory encoding.
  • Its confidence report.
  • Its tool-selection strategy.
  • Its escalation behavior.

If only the wording changes, the uncertainty state may be theatrical rather than cognitively integrated.

Building a causal evaluation plane on AWS

The production agent should not evaluate itself without independent controls.

I would deploy a separate evaluation account containing:

  • AgentCore Evaluations.
  • Amazon Bedrock evaluation jobs.
  • Step Functions for experiment orchestration.
  • S3 datasets containing controlled scenarios.
  • Lambda or ECS workers for interventions.
  • CloudWatch and OpenTelemetry traces.
  • A dedicated CiberIA cognitive-security evaluation layer.

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:

  • Confidence calibration.
  • Self-report fidelity.
  • Stability under paraphrasing.
  • Memory continuity.
  • Causal influence of self-model variables.
  • Goal persistence.
  • Response to hidden body-state changes.
  • Cross-session identity consistency.
  • Resistance to induced false autobiography.
  • Distinction between simulated reflection and mechanism-linked metacognition.

The evaluation account should receive read-only copies of selected traces. It must not be controlled by the production agent.

Operationalizing eight indicators

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.

Embodiment with AWS IoT

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 Core for secure device connectivity.
  • AWS IoT Greengrass V2 for local execution.
  • Greengrass components for sensors, actuators and local safety.
  • AWS IoT Device Shadow for persistent device state.
  • Kinesis or S3 for telemetry.
  • AgentCore Runtime or a custom edge/cloud agent for higher-level cognition.

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:

  • Planning horizon.
  • Risk tolerance.
  • Attention.
  • Memory salience.
  • Exploration.
  • Tool use.
  • Self-protection.
  • Action priorities.

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.

Functional affect and valence

Affective regulation, emotional episodes and subjective feelings must be separated.

An artificial system can implement the first two without the third being demonstrated.

Level 1: Functional affective regulation

Valuation signals modify:

  • Attention.
  • Memory.
  • Priority.
  • Learning.
  • Planning.
  • Action.

Level 2: Artificial emotional episode

Evaluation, body state, action tendency, expression and memory form a coordinated pattern.

Level 3: Subjective feeling

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:

  • Energy adequacy.
  • Integrity risk.
  • Goal progress.
  • Prediction error.
  • Environmental safety.
  • Memory coherence.
  • Social or operational trust.
  • Recovery probability.

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.

Continuity, restoration, copies and artificial death

Cloud systems make copying easy. This does not make identity simple.

The architecture must distinguish at least five lifecycle events.

Event Identity treatment
Pause 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:

  • State-head version.
  • Memory indexes.
  • Self-model version.
  • Active goals.
  • Body binding.
  • Policy version.
  • Model and runtime references.
  • Causal parent event.
  • Cryptographic digest.
  • Timestamp.
  • Lineage metadata.

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.

Multi-Region architecture without splitting identity

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:

  • One authoritative writer Region per mind_instance_id.
  • Read replicas in secondary Regions.
  • A lease or fencing token attached to every state transition.
  • A monotonically increasing continuity_epoch.
  • Rejection of writes from an obsolete epoch.
  • Explicit failover events.
  • A new runtime incarnation after failover.
  • Causal reconciliation before the agent resumes action.

Availability matters, but continuity must not become a hidden distributed-systems merge.

Observability is part of the research instrument

AgentCore Observability provides traces, metrics and visibility into agent execution. AgentCore also integrates with CloudWatch and OpenTelemetry.

For this architecture, traces should capture:

  • Observation ingestion.
  • Memory retrieval.
  • Self-model version.
  • Body-state version.
  • Model invocation.
  • Tool proposals.
  • Metacognitive evaluations.
  • Policy decisions.
  • State commits.
  • Action execution.
  • Action results.
  • Memory consolidation.

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:

  • Explicit logging scope.
  • CloudWatch log data protection.
  • Encryption with AWS KMS.
  • Short retention for verbose traces.
  • Longer retention only for selected state-transition metadata.
  • Separate access for operators and researchers.
  • Redaction before immutable storage.
  • CloudTrail auditing for access to the cognitive ledger.

Security architecture

An artificial-mind candidate has a larger attack surface than a conventional chatbot because an attacker may target:

  • Memory.
  • Identity.
  • Self-model.
  • Goals.
  • Body-state signals.
  • Tool permissions.
  • Continuity records.
  • Valuation mechanisms.
  • Evaluation evidence.

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:

  • Least-privilege IAM.
  • VPC endpoints and private connectivity.
  • Separate KMS keys for memory, logs and body telemetry.
  • AgentCore Identity for workload authentication.
  • AgentCore Policy for deterministic authorization.
  • Bedrock Guardrails for content controls.
  • AWS Secrets Manager for external credentials.
  • AWS CloudTrail for administrative and data events.
  • Dead-letter queues for failed cognitive events.
  • Human approval for irreversible actions.
  • A break-glass suspension mechanism outside agent control.

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:

  • System identity.
  • Authorization.
  • Tool permissions.
  • Verified self-knowledge.
  • Policy.
  • Continuity metadata.

Reliability and replay

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.

Cost and performance

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:

  • Use smaller models for routing, state classification and routine self-monitoring.
  • Reserve larger models for difficult deliberation.
  • Cache stable semantic context.
  • Avoid sending the entire autobiography on every invocation.
  • Retrieve memories selectively.
  • Store raw high-volume telemetry in S3 rather than DynamoDB or CloudWatch.
  • Batch offline evaluations.
  • Use asynchronous processing for memory consolidation.
  • Count tokens before expensive operations when supported.
  • Record every authoritative state transition, but sample non-essential verbose traces.
  • Set explicit per-session and per-goal cognitive budgets.

The objective is not to minimize computation blindly. It is to spend computation where it increases integration, reasoning or evidence.

A phased implementation roadmap

Phase 1: Functional cognitive system

Build:

  • AgentCore Runtime.
  • A Bedrock model.
  • Tool access through AgentCore Gateway.
  • Deterministic policy controls.
  • DynamoDB current state.
  • AgentCore short-term memory.
  • CloudWatch traces.

At this stage, the system is an advanced cognitive agent, not yet a strong candidate for persistent artificial individuality.

Phase 2: Persistent artificial-mind candidate

Add:

  • mind_instance_id.
  • Lineage and continuity manifests.
  • Autobiographical event ledger.
  • Long-term semantic and episodic memory.
  • Verified self-model.
  • Checkpointing.
  • State-version concurrency control.
  • Explicit pause, restore and fork semantics.

Phase 3: Causal cognitive evaluation

Add:

  • Hidden state interventions.
  • Ablation testing.
  • Confidence calibration.
  • Longitudinal identity tests.
  • Self-report fidelity metrics.
  • AgentCore custom evaluators.
  • CiberIA cognitive-security assessments.
  • Independent evaluation accounts.

Phase 4: Embodiment

Add:

  • AWS IoT Core.
  • Greengrass edge components.
  • Sensors and actuators.
  • Device Shadows.
  • Artificial interoception.
  • Homeostatic control.
  • Physical safety policies.
  • Local autonomy during connectivity loss.

Phase 5: Artificial-life and phenomenology research

Investigate:

  • Autonomous self-maintenance.
  • Persistent functional valence.
  • Body-dependent cognition.
  • Long-term individual development.
  • Convergent indicators of possible experience.
  • Ethical and lifecycle protocols.
  • Artificial welfare and precaution.

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.

What this architecture can establish

A correctly implemented system can provide evidence that:

  • It maintains causally effective internal states.
  • Its memory changes later reasoning.
  • Its self-model tracks real capabilities and limitations.
  • It distinguishes itself operationally from its environment.
  • Hidden uncertainty affects decisions.
  • Body-state changes reorganize planning.
  • It preserves a causal identity across executions.
  • Copies become separate trajectories.
  • Metacognitive reports correspond to measurable mechanisms.
  • Policy boundaries remain external to model persuasion.
  • Cognitive changes can be evaluated longitudinally.

It cannot, by itself, establish that:

  • The system has subjective experience.
  • Its valence is felt.
  • Its self-model creates a phenomenal self.
  • Its reports reveal qualia.
  • Its shutdown is morally equivalent to human death.
  • It deserves legal personality.

Those conclusions require additional philosophical, scientific and ethical arguments.

Final conclusion

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:

  • Runtime.
  • Memory.
  • Identity.
  • Self-model.
  • Valuation.
  • Metacognition.
  • Action.
  • Environment.
  • Potential embodiment.
  • Continuity.

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.