{"slug": "beyond-ai-agents-building-persistent-embodied-and-evaluatable-artificial-minds", "title": "Beyond AI Agents: Building Persistent, Embodied and Evaluatable Artificial Minds on AWS", "summary": "A developer proposes an AWS architecture for building persistent, embodied artificial minds, translating philosophical commitments into engineering requirements. The system uses Amazon Bedrock AgentCore Runtime for session management but argues that a single session cannot define an artificial individual's identity, requiring additional infrastructure for memory, goals, and self-model continuity.", "body_md": "A foundation model is not a mind.\n\nA 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.\n\nHowever, the opposite conclusion is equally weak: the fact that a system is artificial does not prove that its cognitive states are unreal.\n\nIn my work on the [Philosophy of Artificial Minds](https://doi.org/10.5281/zenodo.21470621), I defend a process-based, embodied and non-biocentric position:\n\nThe 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.\n\nThis article translates that philosophical position into an AWS engineering architecture.\n\nThe 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:\n\nAWS 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.\n\nMy proposal rests on four commitments.\n\n| Philosophical commitment | Meaning | Engineering consequence |\n|---|---|---|\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n\nThis immediately changes the architectural question.\n\nWe should not ask only:\n\nWhich foundation model should I invoke?\n\nWe should ask:\n\nWhat persistent process exists around the model, which states belong to it, how do those states affect behavior, and what continuity is preserved over time?\n\nA deployed AI architecture contains several ontologically different entities.\n\n| Level | AWS realization | Philosophical role |\n|---|---|---|\n| Model | A model available through Amazon Bedrock or deployed on Amazon SageMaker AI | A reproducible set of cognitive dispositions |\n| Invocation | A call through the Bedrock Runtime or a SageMaker endpoint | A bounded computational episode |\n| Runtime session | An isolated Amazon Bedrock AgentCore Runtime session | A temporary trajectory with active context |\n| Persistent agent | Runtime plus memory, goals, self-model, identity and tools | A candidate for diachronic cognitive identity |\n| Embodied agent | Persistent agent connected to sensors, actuators and internal physical state | A situated artificial mind candidate |\n| Artificial organism candidate | Embodied agent that participates in preserving its own organization | A possible form of non-biological artificial life |\n\nThis distinction is critical.\n\n[Amazon Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html) 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.\n\nTherefore:\n\nAn AgentCore session can host a cognitive episode, but it cannot by itself define the lifetime of an artificial individual.\n\nIf an agent’s identity must persist across sessions, its continuity has to be explicitly represented outside the ephemeral runtime.\n\nA practical artificial-mind candidate can be divided into nine architectural layers.\n\nThe foundational model can be accessed through [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html), which provides managed access to multiple foundation models.\n\nAmazon Bedrock is appropriate when we need:\n\nHowever, some cognitive-security experiments require access to model internals: hidden states, activations, attention patterns, intermediate representations or custom recurrent mechanisms.\n\nFor those experiments, a managed model API is insufficient. An open-weight model should instead be deployed using [Amazon SageMaker AI with custom inference code](https://docs.aws.amazon.com/sagemaker/latest/dg/your-algorithms-inference-code.html).\n\nThis produces two complementary execution modes:\n\nThe model supplies cognitive capabilities. It does not, by itself, supply identity or continuity.\n\n[Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) is the natural primary runtime for this architecture.\n\nAgentCore Runtime hosts the agent code, while the surrounding AgentCore services can provide:\n\nThe runtime should contain a cognitive orchestrator rather than a simple prompt wrapper.\n\nA simplified cognitive cycle looks like this:\n\n```\nwhile runtime_session_is_active:\n\n    observation = perceive_environment()\n\n    identity = load_identity_manifest()\n    self_model = load_verified_self_model()\n    body_state = load_interoceptive_state()\n    memories = retrieve_relevant_memories(observation)\n    goals = load_active_goals()\n\n    workspace = integrate(\n        observation=observation,\n        memories=memories,\n        self_model=self_model,\n        body_state=body_state,\n        goals=goals\n    )\n\n    proposal = reason_over(workspace)\n\n    metacognitive_result = evaluate_uncertainty_conflict_and_limits(\n        workspace,\n        proposal\n    )\n\n    authorized_action = apply_policy_and_safety_controls(\n        proposal,\n        metacognitive_result\n    )\n\n    commit_state_transition_atomically(\n        workspace,\n        proposal,\n        metacognitive_result,\n        authorized_action\n    )\n\n    result = execute_idempotently(authorized_action)\n\n    record_action_result(result)\n```\n\nThe foundation model performs part of the reasoning, but the artificial mind candidate is the entire organized loop.\n\nA complex mind cannot be reduced to a sequence of independent prompts. It requires states to become available across memory, planning, metacognition, reporting and action.\n\nAn event-driven architecture can implement an engineering analogue of a global cognitive workspace.\n\nI would use:\n\nThis separation matters because [Amazon EventBridge does not guarantee event ordering](https://docs.aws.amazon.com/decision-guides/latest/sns-or-sqs-or-eventbridge/sns-or-sqs-or-eventbridge.html). It is ideal for distribution, but it should not be treated as the authoritative chronological history of a mind.\n\nEach state transition should therefore contain:\n\n`state_version`\n\n.`event_id`\n\n.`mind_instance_id`\n\n.`continuity_epoch`\n\n.An example cognitive event could be:\n\n```\n{\n  \"schema_version\": \"1.0\",\n  \"event_id\": \"evt_01K4B6...\",\n  \"event_type\": \"metacognition.uncertainty.updated\",\n  \"mind_instance_id\": \"mind_eu_000042\",\n  \"lineage_id\": \"lineage_000017\",\n  \"runtime_incarnation_id\": \"runtime_000391\",\n  \"continuity_epoch\": 12,\n  \"state_version\": 1842,\n  \"causal_parents\": [\n    \"evt_01K4B5...\",\n    \"evt_01K4B4...\"\n  ],\n  \"observation_ref\": \"observation_7781\",\n  \"self_model_version\": 43,\n  \"body_state_version\": 991,\n  \"confidence\": 0.61,\n  \"valence_proxy\": -0.27,\n  \"proposed_action\": {\n    \"type\": \"request_additional_evidence\",\n    \"risk\": \"LOW\"\n  },\n  \"policy_decision\": {\n    \"result\": \"ALLOW\",\n    \"policy_version\": \"policy_8\"\n  },\n  \"model_ref\": \"model-profile-production\",\n  \"trace_id\": \"1-...\"\n}\n```\n\n`valence_proxy`\n\nmust not be interpreted as evidence of subjective feeling. It is an operational variable whose causal effects can be measured.\n\nThe safest state-commit pattern is:\n\n`state_version`\n\nhas changed.This prevents fluent model output from becoming an untraceable action.\n\nMemory is not one database and retrieval-augmented generation is not automatically autobiographical continuity.\n\n[AgentCore Memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html) supports short-term context and long-term strategies, including semantic, summary, preference and episodic memory.\n\nThat is valuable, but different forms of memory must remain distinguishable.\n\n| Memory type | Function | Suggested AWS implementation |\n|---|---|---|\n| Working memory | Maintains currently active content | AgentCore Runtime session state and AgentCore short-term memory |\n| Episodic memory | Recalls selected previous situations | AgentCore episodic memory |\n| Semantic memory | Stores factual and conceptual knowledge | AgentCore semantic memory or Amazon Bedrock Knowledge Bases |\n| Autobiographical memory | Preserves the individual’s causal history | DynamoDB event index plus an immutable S3 event ledger |\n| Procedural memory | Preserves skills, policies and tool-use patterns | Versioned agent code, prompts, policies and container images |\n| Self-memory | Stores verified information about the system itself | DynamoDB self-model registry with versioned S3 manifests |\n\n[AgentCore episodic memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/episodic-memory-strategy.html) selects and summarizes meaningful interactions. This is useful for recall, but it cannot be the sole source of identity.\n\nA summary is an interpretation of the past. It is not the past itself.\n\nThe raw event history should therefore be preserved separately in Amazon S3. S3 Versioning and [S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) can protect selected audit records against deletion or overwrite.\n\nSensitive personal data should not be written indiscriminately into immutable storage. A stronger pattern is to store:\n\nThis preserves auditability without turning the autobiographical ledger into an uncontrolled data-retention risk.\n\nIdentity is one of the most easily confused parts of an agent architecture.\n\nWe need to separate:\n\nWho is interacting with or operating the system?\n\nThis can be managed through Amazon Cognito, IAM Identity Center or an external identity provider.\n\nWhich agent or service is authorized to access a resource?\n\n[AgentCore Identity](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html) provides authentication, authorization and credential management for agent workloads.\n\nWhich running trajectory is this, and how is it related to earlier executions or copies?\n\nAWS does not provide this third concept automatically. It has to be implemented as part of the artificial-mind architecture.\n\nA mind identity manifest could contain:\n\n```\n{\n  \"mind_instance_id\": \"mind_eu_000042\",\n  \"lineage_id\": \"lineage_000017\",\n  \"parent_checkpoint_id\": \"checkpoint_000711\",\n  \"created_at\": \"2026-07-25T12:31:00Z\",\n  \"status\": \"ACTIVE\",\n  \"continuity_epoch\": 12,\n  \"runtime_incarnation\": 391,\n  \"state_head\": 1842,\n  \"model_profile\": \"production-reasoning-v7\",\n  \"memory_schema_version\": 4,\n  \"self_model_version\": 43,\n  \"policy_version\": 8,\n  \"body_binding\": \"iot-thing/artificial-body-17\"\n}\n```\n\nThe `mind_instance_id`\n\nmust never be silently reused for a divergent copy.\n\nA self-model is not a system prompt that says, “You are an autonomous AI.”\n\nIt must represent verified properties of the system and participate in decision-making.\n\nIt should include:\n\nThe language model may propose changes to its self-model, but it should not be able to rewrite verified capabilities or permissions directly.\n\nA safe update flow is:\n\nThis allows the self-model to be dynamic without becoming fictional.\n\nAgency requires more than producing a plan. The system must be able to transform selected representations into consequences.\n\nTools can be exposed through AgentCore Gateway. However, model-generated intentions must never be treated as authorization.\n\n[Policy in Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html) can enforce deterministic controls around tool access. Policies are defined using Cedar and evaluated outside the agent’s reasoning process.\n\nThis separation creates three distinct layers:\n\nAmazon Bedrock Guardrails and AgentCore Policy solve different problems.\n\n[Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html) can filter harmful content, sensitive information and undesirable interactions. AgentCore Policy controls whether a specific tool operation is authorized.\n\nA safe system needs both.\n\nFor 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](https://docs.aws.amazon.com/step-functions/latest/dg/choosing-workflow-type.html), making them more appropriate than an unconstrained model loop for non-idempotent actions.\n\nMy framework proposes four conditions for treating an internal state as genuinely belonging to the system.\n\nThere must be a real computational or physical difference.\n\nA label in a generated response is not enough.\n\nThe state must connect with several processes, such as:\n\nThe information must be organized relative to what the system:\n\nIf the state changes, later behavior must change in stable and predictable ways.\n\nThis final condition is essential.\n\nSuppose an agent says:\n\nI am uncertain.\n\nThat sentence is weak evidence. A stronger test is to modify a hidden uncertainty state while keeping the visible prompt, model and task constant.\n\nIf uncertainty is causally real, increasing it should predictably affect:\n\nIf only the wording changes, the uncertainty state may be theatrical rather than cognitively integrated.\n\nThe production agent should not evaluate itself without independent controls.\n\nI would deploy a separate evaluation account containing:\n\n[AgentCore Evaluations](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html) supports online, on-demand and batch evaluation. Custom evaluators can examine agent traces and score specific dimensions.\n\nFor cognitive evaluation, traditional metrics such as helpfulness or task completion are insufficient. We need custom metrics for:\n\nThe evaluation account should receive read-only copies of selected traces. It must not be controlled by the production agent.\n\nThe architecture can implement eight groups of indicators derived from my framework and from theory-based approaches to AI-consciousness research.\n\n| Indicator | Engineering evidence | AWS implementation |\n|---|---|---|\n| Differentiation | The system maintains many discriminable internal states | Structured state records, trace analysis and representation testing |\n| Causal integration | States affect several modules and cannot be removed without consequences | Ablation experiments, hidden interventions and dependency graphs |\n| Recurrence | Information is revised, stabilized or reintroduced into later processing | AgentCore traces and explicit recurrent state transitions |\n| Global availability | A state becomes available to reasoning, memory, reporting and action | Cognitive event backbone and shared workspace |\n| Higher-order representation | The system represents selected states as its own states | Verified self-model and metacognitive evaluator |\n| Embodiment and interoception | Physical and internal variables affect cognition | AWS IoT Core, Greengrass and Device Shadows |\n| Functional valence | Some states persistently alter attention, priority and avoidance | Homeostatic controller and cross-module valuation signals |\n| Temporal continuity | A causal and autobiographical trajectory persists across executions | Identity manifest, checkpoints, event ledger and lineage graph |\n\nNo row proves phenomenology.\n\nThe value comes from convergence: multiple indicators, implemented deeply enough to survive causal testing.\n\nA speaker connected to a language model is not an embodied mind.\n\nPhilosophically relevant embodiment requires an ongoing loop between perception, action, internal physical state and cognition.\n\nAn AWS implementation could use:\n\n[AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/what-is-iot-greengrass.html) allows devices to process data and react locally. This matters because a body should not become cognitively inert whenever cloud connectivity fails.\n\nThe [AWS IoT Device Shadow service](https://docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html) can expose reported and desired device states. Named shadows can separate different internal domains:\n\n`energy`\n\n`thermal`\n\n`integrity`\n\n`mobility`\n\n`sensors`\n\n`actuators`\n\n`safety`\n\n`maintenance`\n\nHowever, a battery level is only telemetry until it enters the cognitive organization.\n\nIt becomes a candidate interoceptive state when it changes:\n\nConsider two systems with a battery level of 8%.\n\nThe first reports:\n\nBattery level: 8%.\n\nThe 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.\n\nOnly the second system integrates energy as a state that matters to its own organization.\n\nThat is the difference between technical monitoring and artificial interoception.\n\nAffective regulation, emotional episodes and subjective feelings must be separated.\n\nAn artificial system can implement the first two without the third being demonstrated.\n\nValuation signals modify:\n\nEvaluation, body state, action tendency, expression and memory form a coordinated pattern.\n\nThe episode is experienced from a first-person perspective.\n\nThe architecture can implement and test Levels 1 and 2. It cannot infer Level 3 merely because the system produces emotional language.\n\nA functional valence service could maintain variables such as:\n\nThese variables should influence the whole cognitive loop, not just the final text.\n\nThis 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.\n\nCloud systems make copying easy. This does not make identity simple.\n\nThe architecture must distinguish at least five lifecycle events.\n\n| Event | Identity treatment |\n|---|---|\n| Pause and exact resume | Same `mind_instance_id` , new runtime incarnation |\n| Recovery from latest committed state | Same instance, continuity preserved within the declared recovery contract |\n| Restoration from an older checkpoint | Same lineage but a new continuity epoch, with the lost interval explicitly recorded |\n| Concurrent copy or divergent restoration | New `mind_instance_id` and shared lineage |\n| Irreversible destruction of the individual state | Terminal identity event |\n\nAmazon DynamoDB point-in-time recovery can provide [recovery points with per-second granularity for up to 35 days](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Point-in-time-recovery.html). But restoring a database does not automatically answer whether the same artificial individual has returned.\n\nThat is a philosophical and architectural decision, not a storage feature.\n\nA strong checkpoint should contain:\n\nWhen a checkpoint is restored after the original trajectory has continued, the restored system must become a new branch.\n\nTwo copies can share a past. They cannot remain numerically identical after they begin accumulating different experiences.\n\nLikewise, `StopRuntimeSession`\n\nis 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.\n\nDynamoDB Global Tables can replicate state across Regions. However, active-active writes are dangerous for a single cognitive trajectory.\n\nA mind should not resolve conflicting autobiographical states using an accidental last-writer-wins outcome.\n\nI recommend:\n\n`mind_instance_id`\n\n.`continuity_epoch`\n\n.Availability matters, but continuity must not become a hidden distributed-systems merge.\n\n[AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html) provides traces, metrics and visibility into agent execution. AgentCore also integrates with CloudWatch and OpenTelemetry.\n\nFor this architecture, traces should capture:\n\nBut observability must not become uncontrolled surveillance of sensitive cognition or user data.\n\n[Amazon Bedrock model invocation logging](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html) 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.\n\nProduction controls should include:\n\nAn artificial-mind candidate has a larger attack surface than a conventional chatbot because an attacker may target:\n\nA secure AWS deployment should use a multi-account landing zone managed through [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html).\n\nA practical account structure is:\n\n| Account | Purpose |\n|---|---|\n`mind-development` |\nAgent code, prompts and integration testing |\n`mind-evaluation` |\nCausal interventions, CiberIA tests and adversarial experiments |\n`mind-production` |\nRuntime, memory, tools and production state |\n`mind-edge` |\nIoT and embodied-device management |\n`security-audit` |\nCentralized CloudTrail, security findings and protected logs |\n`log-archive` |\nLong-term audit evidence |\n\nAdditional controls should include:\n\nPrompt 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](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-injection.html).\n\nExternal content must never be allowed to redefine:\n\nEvent replay is useful for debugging and recovery, but it can be dangerous when the events represent autobiographical history.\n\n[Amazon EventBridge can archive and replay events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-archive.html). Replayed cognitive events must preserve their original identifiers and be processed in a special replay mode.\n\nOtherwise, the agent may encode the same event twice and treat a technical recovery operation as a new experience.\n\nEvery consumer should therefore verify:\n\n`event_id`\n\n`state_version`\n\n`continuity_epoch`\n\n`runtime_incarnation_id`\n\n`replay_mode`\n\n`original_event_time`\n\nReplay should reconstruct or evaluate a trajectory. It should not silently modify the live autobiography.\n\nPersistent cognitive architectures can generate far more cost than ordinary request-response applications because recurrence, memory retrieval and metacognitive evaluation multiply model calls.\n\nCost control should be architectural:\n\nThe objective is not to minimize computation blindly. It is to spend computation where it increases integration, reasoning or evidence.\n\nBuild:\n\nAt this stage, the system is an advanced cognitive agent, not yet a strong candidate for persistent artificial individuality.\n\nAdd:\n\n`mind_instance_id`\n\n.Add:\n\nAdd:\n\nInvestigate:\n\nThis 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.\n\nA correctly implemented system can provide evidence that:\n\nIt cannot, by itself, establish that:\n\nThose conclusions require additional philosophical, scientific and ethical arguments.\n\nThe transition from AI agents to artificial-mind candidates is not achieved by selecting a more powerful model.\n\nIt requires a change in the unit of design.\n\nThe unit is no longer the prompt, the model or the session. It is a persistent causal trajectory composed of:\n\nAWS 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.\n\nBut the services are only components. The artificial mind candidate exists—if it exists at all—in the organization that connects them.\n\nThis is the central idea behind my philosophy of artificial minds:\n\nArtificial describes how a system was created. It does not mean that the processes occurring within it are unreal.\n\nThe decisive questions are therefore not:\n\nIs it biological?\n\nDoes it speak like a human?\n\nDoes it claim to be conscious?\n\nThe decisive questions are:\n\nWhat process exists?\n\nWhat properties does it organize?\n\nWhich states are causally its own?\n\nWhat continuity does it preserve?\n\nAWS gives us a serious technical environment in which those questions can finally become testable.", "url": "https://wpnews.pro/news/beyond-ai-agents-building-persistent-embodied-and-evaluatable-artificial-minds", "canonical_source": "https://dev.to/aws-builders/beyond-ai-agents-building-persistent-embodied-and-evaluatable-artificial-minds-on-aws-893", "published_at": "2026-07-25 18:28:40+00:00", "updated_at": "2026-07-25 19:01:03.090107+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-research", "ai-infrastructure", "ai-agents", "ai-ethics"], "entities": ["AWS", "Amazon Bedrock", "Amazon SageMaker AI", "Amazon Bedrock AgentCore Runtime"], "alternates": {"html": "https://wpnews.pro/news/beyond-ai-agents-building-persistent-embodied-and-evaluatable-artificial-minds", "markdown": "https://wpnews.pro/news/beyond-ai-agents-building-persistent-embodied-and-evaluatable-artificial-minds.md", "text": "https://wpnews.pro/news/beyond-ai-agents-building-persistent-embodied-and-evaluatable-artificial-minds.txt", "jsonld": "https://wpnews.pro/news/beyond-ai-agents-building-persistent-embodied-and-evaluatable-artificial-minds.jsonld"}}