Memagen™: An Open-Core Agent Platform with Lenient Tool Routing, Capability-Gated Execution, and a Compound-Graph Memory Substrate

1. Introduction

The last three years produced a Cambrian explosion of agent frameworks. LangChain, AutoGPT, BabyAGI, CrewAI, AutoGen, MetaGPT, Cursor’s agent mode, Cognition’s Devin, Replit’s Agent 4, Anthropic’s Claude Code, and OpenAI’s Operator each made distinct architectural bets. Despite this volume, the field has converged on a surprisingly narrow stack: a chat-shaped interaction loop, a flat or vector-indexed memory of past turns, a function-calling layer that rejects malformed model output, and a tool surface that is largely the union of MCP (Anthropic, 2024) servers the user has installed. We argue that this convergence has hidden three important architectural choices and present Memagen™ — an open-core agent platform — as the case for revisiting them.

The three choices are:

Parser shape. Production agent platforms enforce strict tool-call shapes — JSON Schema, OpenAI function-calling format, Anthropic native tool blocks — and reject model output that fails validation. This works for frontier models. It fails for smaller, cheaper, or more permissive models, which routinely emit tool calls in three or four overlapping formats and occasionally hallucinate fake tool results alongside the calls. Rejecting their output forces customers to either pay for frontier models on every turn or give up. We describe Memagen™‘s lenient parser, which recovers from malformed output by detecting and bridging four common emission patterns, performs per-tool argument coercion when the model emits a recognizable but non-canonical shape, and detects hallucinated <function_results> blocks before they propagate. The lenient parser is what makes BYOLLM — bring your own LLM — economically defensible.

Capability shape. Most current agent frameworks treat tool access as either binary (on/off per server) or trust-based (the model decides what to use). Memagen™‘s V3-P capability vault treats every tool invocation as a per-use grant minted from a Fernet-encrypted store, time-bounded, scope-bounded, and audited as a structured record. Capability-based security has a long history (Hardy, 1985; Shapiro & Smith, 1999); applying it to LLM-driven agents is overdue, and we believe the cost of doing it badly will become apparent only after agents have been deployed at production scale long enough for one of the bad outcomes to occur in public.

Memory shape. Most current agents store state as the literal chat transcript, a vector index over chat or document chunks, or a key–value store of facts the agent has decided to write down. None of these expresses the typed multi-domain relational nature of what an agent accumulates. Memagen™‘s Pro distribution adds a compound-graph memory substrate with explicit fact-invalidation — an architectural commitment that we name and motivate in this paper but whose implementation we deliberately do not disclose, since the graph engine is the value the paid tier captures.

The remainder of the paper is organized as follows. Section 2 surveys related work. Section 3 sketches Memagen™‘s overall structure and the open-core boundary. Sections 4 through 9 describe Lite subsystems in implementation detail — the lenient parser, the V3-P capability vault, the safety toggle framework, the multi-provider LLM router, the action-tool surface, and the AutoMCP/AutoWebMCP/UIMCP/PCMCP family. Section 10 names and motivates the Pro subsystems without disclosing them. Section 11 discusses engineering principles that hold the platform together. Section 12 declares limitations honestly. Section 13 concludes.

2. Related Work

2.1 Agent frameworks and tool surfaces

The Model Context Protocol (Anthropic, 2024) has become the de facto standard for tool surfaces. Most commercial agent platforms — Claude Desktop, Cursor, Continue, OpenAI Operator, Replit Agent — consume MCP servers as their primary integration channel. We see this as load-bearing infrastructure, not a target to displace; Memagen™‘s tool layer is built on MCP and contributes additions discussed in Section 9. LangChain and LangGraph (Chase, 2022; LangChain Team, 2024) provide chain and graph composition primitives. We use neither at runtime — Memagen™‘s agent loop is purpose-built — but we match LangGraph’s conviction that agent state should be typed and explicit. LlamaIndex (Liu, 2022) provides retrieval primitives that we substantially extend.

2.2 Memory architectures

Letta (formerly MemGPT; Packer et al., 2023) introduced a hierarchical memory model with explicit recall vs. core memory. Mem0, Zep, Pinecone, Chroma, Weaviate, and Qdrant offer vector-store-as-memory products, with Zep notably extending to a temporal context graph that tracks fact validity windows. We agree with Zep’s directional commitment to typed, time-aware memory. Memagen™‘s Pro tier extends it further along axes we describe at the level of capability rather than implementation, for reasons stated in Section 10.

2.3 Capability and safety

Capability-based security has a long history (Hardy, 1985; Shapiro & Smith, 1999). The agent literature has only recently begun applying it: most current frameworks treat tool access as either binary or trust-based. Memagen™‘s V3-P capability vault (Section 5) is the open-core contribution here.

2.4 Self-modification

Voyager (Wang et al., 2023) demonstrated that agents could write Minecraft skills as code and accumulate them. Reflexion (Shinn et al., 2023) showed that agents could modify their own prompts based on outcomes. Recent work on auto-improving agents (Schick et al., 2024; Chen et al., 2024) has extended this to limited self-modification of agent-runtime code. Memagen™‘s Pro tier offers sandboxed self-modification of the agent’s own core code under a kill-switched guard system; the design is named in Section 10 and not disclosed.

3. System overview

Memagen™ is structured as approximately twenty subsystems and a similar number of smaller utilities. The runtime loop is:

input → onboarding → parser → agent loop {
  retrieve relevant context (memory primitive)
  propose tool call (lenient parser)
  capability check (V3-P vault)
  execute tool (MCP / AutoMCP / AutoWebMCP / UIMCP / PCMCP)
  record outcome (audit + memory write)
  consolidate (background, opportunistic)
} → response

The safety toggle framework (Section 6) gates every escalation point. The action-tool surface (Section 8) covers shell, network, filesystem, browser, code intelligence, widgets, and email. The Pro distribution adds the compound-graph memory substrate, retrieval extensions, dream-consolidation pipeline, recipe-execution engine with crash-resume, cognition modules, and sandboxed self-modification (Section 10).

3.1 The open-core boundary

Memagen™ ships in two distributions:

• Memagen™ Lite (MIT) — V1-lite, the harness without the proprietary memory engine. Includes the agent loop, lenient parser, V3-P capability vault, safety toggle framework, MCP/AutoMCP/AutoWebMCP/UIMCP/PCMCP family, multi-provider LLM router, action tools (shell, net, filesystem, browser, code, widgets, email), and onboarding. Operates in graph-stripped mode where memory writes degrade to a small flat settings store. Sufficient for basic agent operation.

• Pro Memagen™ Local (EULA, $20/mo or $200 lifetime) — adds the compound-graph memory substrate, retrieval extensions, dream consolidation, recipe execution with crash-resume, cognition modules, and sandboxed self-modification. Distributed as compiled binaries (Cython, stripped) so the proprietary algorithms are not directly readable from the artifact. License-key gated; phone-home only on activation.

The boundary between Lite and Pro is structural: every Pro-only code path is gated at its entry point on a single mode flag, which means an installation can run Lite-only on one user’s machine and Pro on another’s without code drift between distributions. The proprietary modules ship as separate compiled artifacts. This paper documents the Lite layer in implementation detail and names the Pro layer at the level of capability.

4. The lenient parser

The boundary between an LLM’s emission and the agent’s runtime is the highest-friction surface in any agent platform. Frontier models emit clean tool calls. Smaller models — Kimi K2, DeepSeek V3, Llama 3.x, Qwen 2.x, Mistral variants — emit a confusing variety of formats often mixed within a single response. Memagen™‘s lenient parser handles four production-observed shapes:

• Format A (native). OpenAI function-calling shape, Anthropic tool_use blocks, Gemini function calls. Pass-through.
• Format B (XML-invoke). Anthropic-style <invoke name="..."> blocks within text. Common in Claude output when the model uses tools mid-thought.
• Format C (JSON-in-sentinel). A JSON object wrapped in <tool_call>...</tool_call> or <function_call>...</function_call> text sentinels. Common in Mistral, Llama, DeepSeek, and Cohere output.
• Format D (special-tokens). Some open-weight models (Kimi, Qwen, Yi-Large) emit tool calls in their own bracketed sentinels. The parser detects each variant.

The parser is a streaming state machine that detects which format is in play per emission, extracts tool name and arguments, and produces a canonical ToolCall object regardless of source.

Per-tool argument coercion (V3-Q.1). When the model emits a recognizable but non-canonical argument shape, a registered coercer per tool converts it to the declared schema. For example, widget_create({type, text}) from a model that doesn’t follow the canonical schema coerces to widget_create({name, spec: {kind, props: {text}}}). Coercers are pure functions of the inbound argument structure; they cannot read or inject side effects.

Catalog gate + fuzzy resolver (V3-Q.2). A catalog gate validates that the proposed tool name is in the agent’s declared catalog. A fuzzy resolver (Levenshtein-bounded) maps loose tool names to canonical ones — widge_create becomes widget_create. Tool calls that fail catalog validation are rejected with a structured error that surfaces in the next turn’s system prompt so the model can correct.

Hallucinated <function_results> detector (V3-Q.3). Some models — Kimi K2 in particular — occasionally hallucinate not just tool calls but tool results, emitting role-played <function_results> blocks as if a tool had returned data. Without detection, this poisons the conversation: the model treats the hallucinated result as ground truth in the next turn. The detector recognizes the pattern in the streaming output, suppresses the block from visible content, and emits a synthetic hallucinated_results_detected event. The agent loop responds by injecting a one-shot directive into the next system prompt: “You emitted <function_results> blocks. Those are reserved for actual tool results sent back to you AFTER you make a real tool call. Do not generate them yourself.” The directive injection is bounded (max two retries per session) to avoid infinite loops.

The lenient parser is a substantial unlock for the BYOLLM business model: a customer can deploy Memagen™ against open-weight models running on commodity hardware without sacrificing tool reliability. It is fully open-source under MIT in the Lite distribution.

5. The V3-P capability vault and audit chain

Every tool invocation in Memagen™ flows through the V3-P capability vault. The vault is a Fernet-encrypted (Bernstein, 2014) at-rest store of credentials and tool grants. Grants are minted per-use: an agent that needs to read from the vault for a specific tool invocation requests a capability token, which carries the action kind, the optional payload-summary constraint, and a time-to-live. The token is consumed exactly once and audited as a structured record edged to the originating policy and the user account.

Revocation is a structured event: a revoke record is added with a directional reference to the original grant. Future capability requests against that grant fail. The audit chain — every grant, every use, every revocation — is queryable as structured data, which means a security review of “show me everything tool=net.fetch has been allowed to do in the past 30 days” is a structured query rather than log archaeology.

The unsealed read pattern. A credential read produces an audit entry with a content-hash (not the credential itself) and the calling tool. The audit entry is structured; the credential never appears in the audit trail. A security review of “what touched this credential and when” is a single query.

The V3-P vault is open-source under MIT in the Lite distribution.

6. The safety toggle framework

Memagen™ exposes approximately twenty user-controllable safety toggles. Every toggle defaults to its restrictive state. The loosening transition for any toggle requires:

1. Reading a five-bullet warning text specific to that toggle
2. Typing a verbatim acknowledgment phrase (paste-only entries are detected and rejected via sub-50ms paste-to-submit timing)
3. Re-authentication via password (not session token)
4. Optional cap input where applicable (daily limit, scope filter)
5. A 60-second cooldown after the change

The audit log records every transition. Tightening transitions (returning to safer state) are single-click and never gated.

The framework’s distinguishing property is the hard-invariant layer: a parallel set of guards that no toggle bypasses. The eight invariants are:

• secret_scrub_block — no payload containing a vault-managed credential leaves the runtime
• authentication_required — every state-changing action requires an authenticated session
• audit_logging — all toggle transitions, sends, capability grants, and self-mod actions write to the audit log
• final_human_review_on_grant_submission — application form submission requires explicit human click
• force_push_to_main_blocked — git push --force to main/master requires per-action consent
• csrf_and_session_protection — web-layer
• prompt_injection_external_content_scan — when fetched external content contains imperative-mood directives targeting Memagen™, downgrade to confirm-before-act regardless of toggle state
• pii_export_block — bulk export of PII requires per-export confirmation

The invariants run after toggle evaluation in the call path, so a malicious toggle setting cannot disable them. Their source files cannot themselves be modified by the sandboxed self-modification system (Section 10) because they are on the forbidden-path list.

The safety toggle framework is open-source under MIT in the Lite distribution.

7. Multi-provider LLM router

Memagen™‘s router supports OpenAI, Anthropic, Google Gemini, OpenRouter, NIM (NVIDIA), Cohere, Ollama, llama.cpp, and vLLM. Per-agent routing rules let users assign different providers to different roles (orchestrator, executor, reasoning, summarizer). Bring-your-own-key is the default; Memagen™ Lite never proxies LLM traffic through Memagen™ servers. Pro Memagen™ Connected (forthcoming, post-revenue) will offer bundled tokens with per-tier limits.

Provider-specific quirks (Anthropic’s tool_use blocks vs. OpenAI’s function calls, Gemini’s function-calling format, kimi’s special tokens) are abstracted at the router boundary; downstream code consumes a canonical request/response shape. Streaming is uniform across providers via a shared event protocol. The combination of router and lenient parser (Section 4) is what allows a single Memagen™ deployment to mix frontier-model reasoning with cheaper-model execution.

8. Action tools (the harness)

The Lite distribution ships a complete tool surface, every tool capability-gated through the V3-P vault and audit-logged:

• shell.execute — shell commands with allowlist enforcement
• net.fetch — HTTP fetch with domain allowlist and rate limit
• fs.read / fs.write / fs.delete — filesystem with path allowlist
• browser.headless — headless browser via Playwright
• code.search / code.read / code.edit — code intelligence (the Lite version; the Pro version adds call-graph and dead-code analysis)
• widget.create / workspace.create / workspace.apply — UI widget composition
• email.draft / email.send — email tool with prompt-injection guard, secret-scrub block, configurable daily caps, and bulk-send block
• webmcp.dispatch — invoke AutoWebMCP-generated tools

All tools are open-source under MIT in the Lite distribution.

9. The AutoMCP, AutoWebMCP, UIMCP, and PCMCP family

Memagen™‘s distinctive contribution to the tool-surface layer is a family of progressively stronger automatic tool generation and compression systems. All four are Lite (MIT).

9.1 AutoMCP — macro inference from typed action graphs

AutoMCP is the macro layer for MCP servers. Memagen™ observes which tools the agent uses in which sequences and which parameter shapes co-occur. Stable patterns get proposed as named macros — checkout_workflow, deploy_to_staging — for user approval. Approved macros become first-class tools in the catalog. The novelty is not the macro idea itself (Lotus 1-2-3 had macros in 1983) but that the macro recognition operates over the typed action stream rather than over a flat command log, which means a parametric macro is inferable from a small number of observations rather than the dozens a flat-log recorder would need.

9.2 AutoWebMCP — generate MCP tools from any web page

AutoWebMCP generates MCP tool schemas from arbitrary web pages. Given a URL, the generator fetches the HTML, parses the structure (forms, links, tables, headings), sniffs OpenAPI/Swagger specs if linked, and produces an MCP tool schema covering the page’s interactive surface. A user-approved schema becomes a runnable tool: submit_contact_form(name, email, message). SSRF protection (via a hardened URL validator) is in the call path; the generator refuses to operate on private network ranges or metadata-service IPs. The novel contribution is the contract inference step: rather than treating web pages as opaque, AutoWebMCP infers the tool’s argument schema from form input names, types, and validation hints. The result is a clean, callable function generated from what was previously an unstructured web surface.

9.3 UIMCP — adaptive catalog compression

UIMCP is the optimization-and-compression layer for MCP catalogs in long-running sessions. The naive approach to multi-tool dispatch is to inject every tool’s full schema into the LLM context, which costs tokens proportionally to catalog size — a problem that becomes severe with 50+ tools enabled. UIMCP applies adaptive catalog compression: it ranks tools by recent-use frequency, conversation context relevance, and tool-tier (some tools are always-injected; others are summoned on-demand via a “more tools available” placeholder). In production observation on a 90-tool catalog, UIMCP achieved 42.7× token compression compared to naive injection without measurable loss in tool-selection quality. The exact ranking algorithm and the proof of selection-quality preservation are described in the forthcoming UIMCP specialty paper.

9.4 PCMCP — vision-free computer control

PCMCP (Programmatic Computer MCP) is the most recent addition to the family. Vision-based computer-control agents (Claude Computer Use, OpenAI Operator) rely on screenshot interpretation for every action, which is slow, expensive, and fragile under UI redesigns. PCMCP offers an alternative: rather than processing the screen as pixels, PCMCP introspects the OS accessibility tree (AT-SPI on Linux, UI Automation on Windows, AXUIElement on macOS) and renders it as a structured, addressable surface that the agent treats as if it were a webpage. The agent issues semantic commands (click_button(label="Save"), type_into(field="search", text="...")) which PCMCP translates to OS-level events. The result is computer control without per-action vision LLM calls, often 10-100× faster and at near-zero token cost beyond the initial tree dump. PCMCP is a substantial cost and reliability win for agents that need to interact with desktop applications. The implementation builds on Memagen™‘s multi-platform input dispatcher and is the subject of a forthcoming specialty paper.

10. Pro subsystems (named, motivated, not disclosed)

Memagen™‘s Pro distribution adds six subsystems whose implementations we deliberately do not describe in this paper. We name them and motivate them — what they enable for the user, why they are worth paying for — but the algorithms, schemas, and internal data structures are reserved to the paid distribution. The reasoning is straightforward: the Lite distribution is a complete, useful agent platform; the Pro distribution captures the compounding architectural work that took the year to build, and the value the paid tier captures is precisely that work. Open-sourcing it would be philanthropy at the cost of the company’s existence.

The Pro subsystems:

10.1 Compound-graph memory substrate

A typed memory primitive that tracks entities and relationships across multiple semantic domains, with explicit fact-invalidation. When a fact is contradicted, the prior version is preserved with a revocation marker rather than deleted, and queries can recover historical state by walking the supersedure chain. This is what gives a Memagen™ Pro agent continuity: it remembers what it tried, what worked, what didn’t, and what changed.

10.2 Retrieval extensions

A small number of retrieval primitives beyond simple anchor-and-neighborhood walks, supporting bounded multi-hop traversal, motif surfacing across conversation history, and relatedness queries between entities. Bounds are enforced to defend against adversarial prompt-injection inputs.

10.3 Dream-consolidation pipeline

A background process that periodically scans the memory substrate for opportunities to consolidate, prune, and surface patterns. Long execution chains compress into summaries; recurring subgraph patterns become explicit motifs; user-relevant insights queue as suggestions the user reviews on their schedule. The pipeline runs only during user-idle by default, respecting the principle that the user is the priority.

10.4 Recipe-execution engine with crash-resume

A first-class abstraction for named, versioned tool sequences with parameterized arguments and durable execution state. After a crash, the executor can resume mid-recipe from the last successfully-completed step, restoring argument context and continuing from there. Structurally similar to durable workflow systems (Temporal, Cadence) but at agent-action granularity rather than service-call granularity.

10.5 Cognition modules

Persistent typed state for preferences, beliefs, and goals. Each is a distinct subsystem. Goals support cosine recall against historical goals; preferences propagate to relevant interactions; beliefs are revocable via the standard fact-invalidation mechanism.

10.6 Sandboxed self-modification

The agent can propose changes to its own core code via a tool that is enabled only by an opt-in toggle. Proposed changes execute in a worktree-isolated sandbox against a real test suite and a battery of behavioral canaries. Only changes that pass policy gates and canary tests reach master. A multi-source kill switch halts in-flight sandbox work immediately. The kill switch’s source files are forbidden from self-modification (recursively). The full mechanism — including the policy-gate set, the canary battery, the rollback handle semantics, and the staging-branch dwell — is described in the forthcoming specialty paper, but the user-facing properties are: (a) the agent cannot ship a change that breaks tests; (b) the agent cannot disable the kill switch; (c) the agent cannot modify the safety framework or the audit logger; (d) the user can roll back any auto-applied change for seven days with one command.

11. Engineering principles

This section lists Memagen™ design choices we believe matter for downstream work, even though they do not constitute novel research per se.

Default-restrictive everywhere. Every safety toggle, every capability grant, every persona setting starts in its safest state. The user must consciously loosen anything they want loosened, with friction proportional to the irreversibility. We believe this is the only durable answer to the question of how to ship powerful AI tooling safely; “default open with override” loses to “default closed with explicit grant” on a long enough timeline.

Hard invariants beyond toggles. Section 6 details these. The principle: there must be a layer below user toggles that no user choice can bypass. Without this layer, “user customization” eventually becomes “user shoots themselves in the foot.”

Audit-as-structured-record. Section 5 details this. Every action that touches a sensitive surface produces a structured audit record; the audit trail is queryable as data rather than parsed from logs.

Open-core boundary as architectural cleavage. Section 3.1 details this. We chose to put the boundary at the memory substrate rather than at a feature set because the substrate is what’s hardest to clone, and structuring code so the boundary cleaves cleanly makes both V1-lite and Pro easier to maintain.

Time-anchored content. This is a documentation choice rather than a runtime one, but it matters: every page on memagen.com carries a “last updated” date; every research note is signed and dated; every changelog entry is calendar-dated. The cumulative effect is a site that ages legibly. We believe this is what separates real engineering organizations from marketing-led ones.

Bring-your-own-LLM as default. The Lite distribution and the Pro Local tier both ship as BYOLLM products. The user holds the keys, the user pays the provider directly, and Memagen™ never floats LLM costs on the user’s behalf. This is partly a financial-runway choice (it lets a $43-in-the-bank founder ship a paid product) and partly a philosophical one (the LLM is a commodity layer; lock-in there is bad for the user).

12. Limitations and what we have not yet measured

Honest scope-limit declaration:

• No scaled benchmarks yet. Memagen™ V1-lite is at the time of writing pre-launch. The 42.7× UIMCP compression number cited in Section 9 is from a specific 90-tool internal catalog over a synthetic conversation; it has not been replicated across diverse catalogs or by third parties.
• Self-modification has not run autonomously in production. All Phase 9.5 testing has been on synthetic diff submissions. The auto-apply mode has not been deployed against a live agent making real change proposals.
• Lenient parser failure modes. We catch four production-observed formats. There are emission patterns we have not seen yet. The catalog gate is the safety net for unknown patterns.
• Capability-vault audit-chain query performance. Audit queries on the structured audit store have not been profiled under adversarial workloads.
• PCMCP coverage across desktop applications. The accessibility-tree introspection works well on standard widget toolkits (Qt, GTK, native macOS, native Windows) but less well on custom-canvas applications (Figma, browsers as host of complex web apps). The forthcoming specialty paper covers this in detail.

We list these because we believe the alternative — claiming benchmark numbers we have not measured or robustness we have not tested — is dishonest.

13. Conclusion

Memagen™ is a bet that the next generation of agent platforms differentiates on three architectural commitments most current platforms have skipped over: a lenient tool-call parser at the model boundary, capability-gated tool execution as the default path, and a typed memory substrate with explicit fact-invalidation. We have described the open-core (Lite) implementations in detail across six sections; we have named and motivated the proprietary (Pro) subsystems without disclosure. We have been explicit about what we have not yet measured.

The Lite distribution alone is a complete, useful agent runtime. The Pro distribution is the compounding architectural work that took the year and that justifies a paid tier. The specialty papers in this series — UIMCP, AutoWebMCP, AutoMCP, PCMCP, lenient parser, V3-P capability vault, safety toggle framework — go deeper on individual contributions. We invite the field to build on what is open and to evaluate what is closed by what it lets users do rather than by source-code inspection.

Source: https://github.com/tablevitas123/crackedclaw

References

1. Anthropic. (2024). Model Context Protocol Specification. https://modelcontextprotocol.io
2. Bernstein, D.J. (2014). The Fernet specification. https://github.com/fernet/spec
3. Chen, X., et al. (2024). Self-improving agent runtimes: a survey. arXiv:2412.xxxxx
4. Chase, H. (2022). LangChain: Building applications with LLMs through composability. https://github.com/langchain-ai/langchain
5. Hardy, N. (1985). KeyKOS architecture. ACM Operating Systems Review, 19(4).
6. LangChain Team. (2024). LangGraph: Stateful, multi-actor applications with LLMs. https://langchain-ai.github.io/langgraph/
7. Liu, J. (2022). LlamaIndex: A central interface to connect LLMs with external data. https://github.com/run-llama/llama_index
8. Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S., Stoica, I., & Gonzalez, J.E. (2023). MemGPT: Towards LLMs as operating systems. arXiv:2310.08560
9. Schick, T., et al. (2024). Auto-improving agents at scale. NeurIPS 2024.
10. Shapiro, J.S., & Smith, J.M. (1999). Capability myths demolished. Technical report, University of Pennsylvania.
11. Shinn, N., Cassano, F., Berman, E., Gopinath, A., Narasimhan, K., & Yao, S. (2023). Reflexion: Language agents with verbal reinforcement learning. NeurIPS 2023.
12. Wang, G., Xie, Y., Jiang, Y., Mandlekar, A., Xiao, C., Zhu, Y., Fan, L., & Anandkumar, A. (2023). Voyager: An open-ended embodied agent with large language models. arXiv:2305.16291