Metadata-Version: 2.2
Name: agentcore-graph
Version: 0.1.3
Summary: Native agent-graph runtime with C++ execution, explicit state patches, resumable checkpoints, and Python bindings.
Keywords: agents,graphs,workflows,runtime,llm
Author: Michael Avina
License: Common Public Attribution License Version 1.0
         
         Version 1.0
         Submitted: June 26, 2007
         Submitter: Ross Mayfield
         SPDX short identifier: CPAL-1.0
         
         Steward:
         Socialtext
         
         1. "Definitions"
         
         1.0.1 "Commercial Use" means distribution or otherwise making the Covered Code available to a third party.
         
         1.1 "Contributor" means each entity that creates or contributes to the creation of Modifications.
         
         1.2 "Contributor Version" means the combination of the Original Code, prior Modifications used by a Contributor, and the Modifications made by that particular Contributor.
         
         1.3 "Covered Code" means the Original Code or Modifications or the combination of the Original Code and Modifications, in each case including portions thereof.
         
         1.4 "Electronic Distribution Mechanism" means a mechanism generally accepted in the software development community for the electronic transfer of data.
         
         1.5 "Executable" means Covered Code in any form other than Source Code.
         
         1.6 "Initial Developer" means the individual or entity identified as the Initial Developer in the Source Code notice required by Exhibit A.
         
         1.7 "Larger Work" means a work which combines Covered Code or portions thereof with code not governed by the terms of this License.
         
         1.8 "License" means this document.
         
         1.8.1 "Licensable" means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently acquired, any and all of the rights conveyed herein.
         
         1.9 "Modifications" means any addition to or deletion from the substance or structure of either the Original Code or any previous Modifications. When Covered Code is released as a series of files, a Modification is:
         
         A. Any addition to or deletion from the contents of a file containing Original Code or previous Modifications.
         
         B. Any new file that contains any part of the Original Code or previous Modifications.
         
         1.10 "Original Code" means Source Code of computer software code which is described in the Source Code notice required by Exhibit A as Original Code, and which, at the time of its release under this License is not already Covered Code governed by this License.
         
         1.10.1 "Patent Claims" means any patent claim(s), now owned or hereafter acquired, including without limitation, method, process, and apparatus claims, in any patent Licensable by grantor.
         
         1.11 "Source Code" means the preferred form of the Covered Code for making modifications to it, including all modules it contains, plus any associated interface definition files, scripts used to control compilation and installation of an Executable, or source code differential comparisons against either the Original Code or another well known, available Covered Code of the Contributor's choice. The Source Code can be in a compressed or archival form, provided the appropriate decompression or de-archiving software is widely available for no charge.
         
         1.12 "You" (or "Your") means an individual or a legal entity exercising rights under, and complying with all of the terms of, this License or a future version of this License issued under Section 6.1. For legal entities, "You" includes any entity which controls, is controlled by, or is under common control with You. For purposes of this definition, "control" means (a) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (b) ownership of more than fifty percent (50%) of the outstanding shares or beneficial ownership of such entity.
         
         2. Source Code License.
         
         2.1 The Initial Developer Grant.
         
         The Initial Developer hereby grants You a world-wide, royalty-free, non-exclusive license, subject to third party intellectual property claims:
         
         (a) under intellectual property rights (other than patent or trademark) Licensable by Initial Developer to use, reproduce, modify, display, perform, sublicense and distribute the Original Code (or portions thereof) with or without Modifications, and/or as part of a Larger Work; and
         
         (b) under Patent Claims infringed by the making, using or selling of Original Code, to make, have made, use, practice, sell, and offer for sale, and/or otherwise dispose of the Original Code (or portions thereof).
         
         (c) the licenses granted in this Section 2.1(a) and (b) are effective on the date Initial Developer first distributes Original Code under the terms of this License.
         
         (d) Notwithstanding Section 2.1(b) above, no patent license is granted: 1) for code that You delete from the Original Code; 2) separate from the Original Code; or 3) for infringements caused by: i) the modification of the Original Code or ii) the combination of the Original Code with other software or devices.
         
         2.2 Contributor Grant.
         
         Subject to third party intellectual property claims, each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license
         
         (a) under intellectual property rights (other than patent or trademark) Licensable by Contributor, to use, reproduce, modify, display, perform, sublicense and distribute the Modifications created by such Contributor (or portions thereof) either on an unmodified basis, with other Modifications, as Covered Code and/or as part of a Larger Work; and
         
         (b) under Patent Claims infringed by the making, using, or selling of Modifications made by that Contributor either alone and/or in combination with its Contributor Version (or portions of such combination), to make, use, sell, offer for sale, have made, and/or otherwise dispose of: 1) Modifications made by that Contributor (or portions thereof); and 2) the combination of Modifications made by that Contributor with its Contributor Version (or portions of such combination).
         
         (c) the licenses granted in Sections 2.2(a) and 2.2(b) are effective on the date Contributor first makes Commercial Use of the Covered Code.
         
         (d) Notwithstanding Section 2.2(b) above, no patent license is granted: 1) for any code that Contributor has deleted from the Contributor Version; 2) separate from the Contributor Version; 3) for infringements caused by: i) third party modifications of Contributor Version or ii) the combination of Modifications made by that Contributor with other software (except as part of the Contributor Version) or other devices; or 4) under Patent Claims infringed by Covered Code in the absence of Modifications made by that Contributor.
         
         3. Distribution Obligations.
         
         3.1 Application of License.
         
         The Modifications which You create or to which You contribute are governed by the terms of this License, including without limitation Section 2.2. The Source Code version of Covered Code may be distributed only under the terms of this License or a future version of this License released under Section 6.1, and You must include a copy of this License with every copy of the Source Code You distribute. You may not offer or impose any terms on any Source Code version that alters or restricts the applicable version of this License or the recipients' rights hereunder. However, You may include an additional document offering the additional rights described in Section 3.5.
         
         3.2 Availability of Source Code.
         
         Any Modification which You create or to which You contribute must be made available in Source Code form under the terms of this License either on the same media as an Executable version or via an accepted Electronic Distribution Mechanism to anyone to whom you made an Executable version available; and if made available via Electronic Distribution Mechanism, must remain available for at least twelve (12) months after the date it initially became available, or at least six (6) months after a subsequent version of that particular Modification has been made available to such recipients. You are responsible for ensuring that the Source Code version remains available even if the Electronic Distribution Mechanism is maintained by a third party.
         
         3.3 Description of Modifications.
         
         You must cause all Covered Code to which You contribute to contain a file documenting the changes You made to create that Covered Code and the date of any change. You must include a prominent statement that the Modification is derived, directly or indirectly, from Original Code provided by the Initial Developer and including the name of the Initial Developer in (a) the Source Code, and (b) in any notice in an Executable version or related documentation in which You describe the origin or ownership of the Covered Code.
         
         3.4 Intellectual Property Matters
         
         (a) Third Party Claims.
         
         If Contributor has knowledge that a license under a third party's intellectual property rights is required to exercise the rights granted by such Contributor under Sections 2.1 or 2.2, Contributor must include a text file with the Source Code distribution titled "LEGAL" which describes the claim and the party making the claim in sufficient detail that a recipient will know whom to contact. If Contributor obtains such knowledge after the Modification is made available as described in Section 3.2, Contributor shall promptly modify the LEGAL file in all copies Contributor makes available thereafter and shall take other steps (such as notifying appropriate mailing lists or newsgroups) reasonably calculated to inform those who received the Covered Code that new knowledge has been obtained.
         
         (b) Contributor APIs.
         
         If Contributor's Modifications include an application programming interface and Contributor has knowledge of patent licenses which are reasonably necessary to implement that API, Contributor must also include this information in the LEGAL file.
         
         (c) Representations.
         
         Contributor represents that, except as disclosed pursuant to Section 3.4(a) above, Contributor believes that Contributor's Modifications are Contributor's original creation(s) and/or Contributor has sufficient rights to grant the rights conveyed by this License.
         
         3.5 Required Notices.
         
         You must duplicate the notice in Exhibit A in each file of the Source Code. If it is not possible to put such notice in a particular Source Code file due to its structure, then You must include such notice in a location (such as a relevant directory) where a user would be likely to look for such a notice. If You created one or more Modification(s) You may add your name as a Contributor to the notice described in Exhibit A. You must also duplicate this License in any documentation for the Source Code where You describe recipients' rights or ownership rights relating to Covered Code. You may choose to offer, and to charge a fee for, warranty, support, indemnity or liability obligations to one or more recipients of Covered Code. However, You may do so only on Your own behalf, and not on behalf of the Initial Developer or any Contributor. You must make it absolutely clear than any such warranty, support, indemnity or liability obligation is offered by You alone, and You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of warranty, support, indemnity or liability terms You offer.
         
         3.6 Distribution of Executable Versions.
         
         You may distribute Covered Code in Executable form only if the requirements of Section 3.1-3.5 have been met for that Covered Code, and if You include a notice stating that the Source Code version of the Covered Code is available under the terms of this License, including a description of how and where You have fulfilled the obligations of Section 3.2. The notice must be conspicuously included in any notice in an Executable version, related documentation or collateral in which You describe recipients' rights relating to the Covered Code. You may distribute the Executable version of Covered Code or ownership rights under a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable version does not attempt to limit or alter the recipient's rights in the Source Code version from the rights set forth in this License. If You distribute the Executable version under a different license You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer, Original Developer or any Contributor. You hereby agree to indemnify the Initial Developer, Original Developer and every Contributor for any liability incurred by the Initial Developer, Original Developer or such Contributor as a result of any such terms You offer.
         
         3.7 Larger Works.
         
         You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code.
         
         4. Inability to Comply Due to Statute or Regulation.
         
         If it is impossible for You to comply with any of the terms of this License with respect to some or all of the Covered Code due to statute, judicial order, or regulation then You must: (a) comply with the terms of this License to the maximum extent possible; and (b) describe the limitations and the code they affect. Such description must be included in the LEGAL file described in Section 3.4 and must be included with all distributions of the Source Code. Except to the extent prohibited by statute or regulation, such description must be sufficiently detailed for a recipient of ordinary skill to be able to understand it.
         
         5. Application of this License.
         
         This License applies to code to which the Initial Developer has attached the notice in Exhibit A and to related Covered Code.
         
         6. Versions of the License.
         
         6.1 New Versions.
         
         Socialtext, Inc. ("Socialtext") may publish revised and/or new versions of the License from time to time. Each version will be given a distinguishing version number.
         
         6.2 Effect of New Versions.
         
         Once Covered Code has been published under a particular version of the License, You may always continue to use it under the terms of that version. You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Socialtext. No one other than Socialtext has the right to modify the terms applicable to Covered Code created under this License.
         
         6.3 Derivative Works.
         
         If You create or use a modified version of this License (which you may only do in order to apply it to code which is not already Covered Code governed by this License), You must (a) rename Your license so that the phrases "Socialtext", "CPAL" or any confusingly similar phrase do not appear in your license (except to note that your license differs from this License) and (b) otherwise make it clear that Your version of the license contains terms which differ from the CPAL. (Filling in the name of the Initial Developer, Original Developer, Original Code or Contributor in the notice described in Exhibit A shall not of themselves be deemed to be modifications of this License.)
         
         7. DISCLAIMER OF WARRANTY.
         
         COVERED CODE IS PROVIDED UNDER THIS LICENSE ON AN "AS IS" BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL DEVELOPER, ORIGINAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER.
         
         8. TERMINATION.
         
         8.1 This License and the rights granted hereunder will terminate automatically if You fail to comply with terms herein and fail to cure such breach within 30 days of becoming aware of the breach. All sublicenses to the Covered Code which are properly granted shall survive any termination of this License. Provisions which, by their nature, must remain in effect beyond the termination of this License shall survive.
         
         8.2 If You initiate litigation by asserting a patent infringement claim (excluding declatory judgment actions) against Initial Developer, Original Developer or a Contributor (the Initial Developer, Original Developer or Contributor against whom You file such action is referred to as "Participant") alleging that:
         
         (a) such Participant's Contributor Version directly or indirectly infringes any patent, then any and all rights granted by such Participant to You under Sections 2.1 and/or 2.2 of this License shall, upon 60 days notice from Participant terminate prospectively, unless if within 60 days after receipt of notice You either: (i) agree in writing to pay Participant a mutually agreeable reasonable royalty for Your past and future use of Modifications made by such Participant, or (ii) withdraw Your litigation claim with respect to the Contributor Version against such Participant.
         
         If within 60 days of notice, a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Participant to You under Sections 2.1 and/or 2.2 automatically terminate at the expiration of the 60 day notice period specified above.
         
         (b) any software, hardware, or device, other than such Participant's Contributor Version, directly or indirectly infringes any patent, then any rights granted to You by such Participant under Sections 2.1(b) and 2.2(b) are revoked effective as of the date You first made, used, sold, distributed, or had made, Modifications made by that Participant.
         
         8.3 If You assert a patent infringement claim against Participant alleging that such Participant's Contributor Version directly or indirectly infringes any patent where such claim is resolved (such as by license or settlement) prior to the initiation of patent infringement litigation, then the reasonable value of the licenses granted by such Participant under Sections 2.1 or 2.2 shall be taken into account in determining the amount or value of any payment or license.
         
         8.4 In the event of termination under Sections 8.1 or 8.2 above, all end user license agreements (excluding distributors and resellers) which have been validly granted by You or any distributor hereunder prior to termination shall survive termination.
         
         9. LIMITATION OF LIABILITY.
         
         UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER TORT (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL YOU, THE INITIAL DEVELOPER, ORIGINAL DEVELOPER, ANY OTHER CONTRIBUTOR, OR ANY DISTRIBUTOR OF COVERED CODE, OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO ANY PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF LIABILITY SHALL NOT APPLY TO LIABILITY FOR DEATH OR PERSONAL INJURY RESULTING FROM SUCH PARTY'S NEGLIGENCE TO THE EXTENT APPLICABLE LAW PROHIBITS SUCH LIMITATION. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU.
         
         10. U.S. GOVERNMENT END USERS.
         
         The Covered Code is a "commercial item," as that term is defined in 48 C.F.R. 2.101 (Oct. 1995), consisting of "commercial computer software" and "commercial computer software documentation," as such terms are used in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48 C.F.R. 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995), all U.S. Government End Users acquire Covered Code with only those rights set forth herein.
         
         11. MISCELLANEOUS.
         
         This License represents the complete agreement concerning subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. This License shall be governed by California law provisions (except to the extent applicable law, if any, provides otherwise), excluding its conflict-of-law provisions. With respect to disputes in which at least one party is a citizen of, or an entity chartered or registered to do business in the United States of America, any litigation relating to this License shall be subject to the jurisdiction of the Federal Courts of the Northern District of California, with venue lying in Santa Clara County, California, with the losing party responsible for costs, including without limitation, court costs and reasonable attorneys' fees and expenses. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not apply to this License.
         
         12. RESPONSIBILITY FOR CLAIMS.
         
         As between Initial Developer, Original Developer and the Contributors, each party is responsible for claims and damages arising, directly or indirectly, out of its utilization of rights under this License and You agree to work with Initial Developer, Original Developer and Contributors to distribute such responsibility on an equitable basis. Nothing herein is intended or shall be deemed to constitute any admission of liability.
         
         13. MULTIPLE-LICENSED CODE.
         
         Initial Developer may designate portions of the Covered Code as Multiple-Licensed. Multiple-Licensed means that the Initial Developer permits you to utilize portions of the Covered Code under Your choice of the CPAL or the alternative licenses, if any, specified by the Initial Developer in the file described in Exhibit A.
         
         14. ADDITIONAL TERM: ATTRIBUTION
         
         (a) As a modest attribution to the organizer of the development of the Original Code ("Original Developer"), in the hope that its promotional value may help justify the time, money and effort invested in writing the Original Code, the Original Developer may include in Exhibit B ("Attribution Information") a requirement that each time an Executable and Source Code or a Larger Work is launched or initially run (which includes initiating a session), a prominent display of the Original Developer's Attribution Information (as defined below) must occur on the graphic user interface employed by the end user to access such Covered Code (which may include display on a splash screen), if any. The size of the graphic image should be consistent with the size of the other elements of the Attribution Information. If the access by the end user to the Executable and Source Code does not create a graphic user interface for access to the Covered Code, this obligation shall not apply. If the Original Code displays such Attribution Information in a particular form (such as in the form of a splash screen, notice at login, an "about" display, or dedicated attribution area on user interface screens), continued use of such form for that Attribution Information is one way of meeting this requirement for notice.
         
         (b) Attribution information may only include a copyright notice, a brief phrase, graphic image and a URL ("Attribution Information") and is subject to the Attribution Limits as defined below. For these purposes, prominent shall mean display for sufficient duration to give reasonable notice to the user of the identity of the Original Developer and that if You include Attribution Information or similar information for other parties, You must ensure that the Attribution Information for the Original Developer shall be no less prominent than such Attribution Information or similar information for the other party. For greater certainty, the Original Developer may choose to specify in Exhibit B below that the above attribution requirement only applies to an Executable and Source Code resulting from the Original Code or any Modification, but not a Larger Work. The intent is to provide for reasonably modest attribution, therefore the Original Developer cannot require that You display, at any time, more than the following information as Attribution Information: (a) a copyright notice including the name of the Original Developer; (b) a word or one phrase (not exceeding 10 words); (c) one graphic image provided by the Original Developer; and (d) a URL (collectively, the "Attribution Limits").
         
         (c) If Exhibit B does not include any Attribution Information, then there are no requirements for You to display any Attribution Information of the Original Developer.
         
         (d) You acknowledge that all trademarks, service marks and/or trade names contained within the Attribution Information distributed with the Covered Code are the exclusive property of their owners and may only be used with the permission of their owners, or under circumstances otherwise permitted by law or as expressly set out in this License.
         
         15. ADDITIONAL TERM: NETWORK USE.
         
         The term "External Deployment" means the use, distribution, or communication of the Original Code or Modifications in any way such that the Original Code or Modifications may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Code or Modifications as a distribution under section 3.1 and make Source Code available under Section 3.2.
         
         EXHIBIT A. Common Public Attribution License Version 1.0.
         
         "The contents of this file are subject to the Common Public Attribution License Version 1.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://opensource.org/license/cpal-1.0. The License is based on the Mozilla Public License Version 1.1 but Sections 14 and 15 have been added to cover use of software over a computer network and provide for limited attribution for the Original Developer.
         
         In addition, Exhibit A has been modified to be consistent with Exhibit B.
         
         Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License.
         
         The Original Code is AgentCore.
         
         The Original Developer is not the Initial Developer and is ________. If left blank, the Original Developer is the Initial Developer.
         
         The Initial Developer of the Original Code is Michael Avina. All portions of the code written by Michael Avina are Copyright (c) 2026 Michael Avina. All Rights Reserved.
         
         Contributor ________.
         
         Alternatively, the contents of this file may be used under the terms of the _____ license (the [___] License), in which case the provisions of [______] License are applicable instead of those above.
         
         If you wish to allow use of your version of this file only under the terms of the [____] License and not to allow others to use your version of this file under the CPAL, indicate your decision by deleting the provisions above and replace them with the notice and other provisions required by the [___] License. If you do not delete the provisions above, a recipient may use your version of this file under either the CPAL or the [___] License."
         
         [NOTE: The text of this Exhibit A may differ slightly from the text of the notices in the Source Code files of the Original Code. You should use the text of this Exhibit A rather than the text found in the Original Code Source Code for Your Modifications.]
         
         EXHIBIT B. Attribution Information
         
         Attribution Copyright Notice: Copyright (c) 2026 Michael Avina. All Rights Reserved.
         
         Attribution Phrase (not exceeding 10 words): Created by Michael Avina
         
         Attribution URL:
         
         Graphic Image as provided in the Covered Code, if any.
         
         Display of Attribution Information is required in Larger Works which are defined in the CPAL as a work which combines Covered Code or portions thereof with code not governed by the terms of the CPAL.
         
Classifier: Development Status :: 3 - Alpha
Classifier: Intended Audience :: Developers
Classifier: License :: Other/Proprietary License
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: C++
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Classifier: Topic :: System :: Distributed Computing
Project-URL: Homepage, https://github.com/mavin2009/agentcore
Project-URL: Documentation, https://github.com/mavin2009/agentcore/tree/main/docs
Project-URL: Repository, https://github.com/mavin2009/agentcore
Project-URL: Issues, https://github.com/mavin2009/agentcore/issues
Requires-Python: >=3.9
Description-Content-Type: text/markdown

# AgentCore

AgentCore is a native agent-graph runtime written in C++20. It is organized around a compact execution kernel, typed workflow state, explicit state patches, a multi-worker scheduler, append-only traces, resumable checkpoints, tool/model registries, public stream events, persistent subgraph sessions, subgraph composition, and knowledge-graph state.

The project is split into a small number of subsystems with clear boundaries:

- graph IR for immutable workflow structure and compiled routing data
- state storage for typed fields, blobs, patch logs, and knowledge-graph data
- execution for stepping, patch commit, trace emission, checkpointing, and resume
- runtime for node execution, scheduling, async wait handling, and adapters
- bindings and examples for the Python API and end-to-end reference programs

## Documentation

The root README is the landing page. The task-oriented guides live under [`./docs/README.md`](./docs/README.md):

- [`./docs/quickstarts/python.md`](./docs/quickstarts/python.md): build the Python bindings, define a graph, invoke it, stream events, and use persistent subgraph sessions
- [`./docs/quickstarts/cpp.md`](./docs/quickstarts/cpp.md): build and embed the C++ runtime, construct graphs, and run the native examples
- [`./docs/concepts/runtime-model.md`](./docs/concepts/runtime-model.md): execution model, state patches, joins, persistent subgraph sessions, knowledge graph state, checkpoints, and streaming
- [`./docs/reference/api.md`](./docs/reference/api.md): Python surface summary and the key C++ headers and types
- [`./docs/comparisons/langgraph-head-to-head.md`](./docs/comparisons/langgraph-head-to-head.md): measured head-to-head numbers against upstream LangGraph and reproduction commands
- [`./docs/migration/langgraph-to-agentcore.md`](./docs/migration/langgraph-to-agentcore.md): one-page guide for moving a LangGraph-style `StateGraph` to AgentCore
- [`./docs/operations/validation.md`](./docs/operations/validation.md): test, smoke, persistent-session benchmark, and replay validation entry points

## Why This Shape

The runtime is intentionally built around a small engine instead of a large orchestration layer.

The execution engine is responsible for a narrow set of operations:

- start a run from a `GraphDefinition`
- execute one scheduled node
- apply its `StatePatch`
- emit trace and checkpoint records
- choose and enqueue follow-on work
- resume from a stored checkpoint snapshot

That separation is visible in the public API in [`./agentcore/include/agentcore/execution/engine.h`](./agentcore/include/agentcore/execution/engine.h). The reason for keeping the engine narrow is straightforward: it keeps control flow predictable, reduces hidden mutation, and makes replay/resume mechanics easier to reason about than if tool logic, model logic, or application policy were embedded in the kernel itself.

Several other design decisions follow from the same goal:

- Flat graph IR: nodes and edges are index-based structs with compiled routing tables. This keeps graph lookup and routing simple and cache-friendly and avoids virtual-dispatch-heavy graph metadata in the hot path.
- Explicit state patches: nodes return a `NodeResult` and a `StatePatch` instead of mutating global state in place. That gives the engine a single commit point for trace emission, checkpointing, and replay.
- Typed hot state plus blob references: durable state lives in `WorkflowState::fields`, while larger payloads live in the `BlobStore`. The intent is to keep frequently-read execution state small while still allowing larger artifacts to flow through the graph.
- Scheduler separated from execution: the scheduler owns task queues, worker threads, and async waiter promotion, while the engine owns semantics. This lets concurrency policy evolve without turning the execution loop into a thread-management subsystem.
- Knowledge graph in the state layer: graph memory is treated as first-class runtime state, not as an external sidecar. That keeps graph-aware workflows, subscriptions, and replay under the same state and checkpoint model as ordinary field updates.
- Persistent child sessions are stored as isolated child snapshots plus explicit input/output bindings. This keeps concurrent distinct sessions safe, makes same-session conflicts reject cleanly, and prevents hidden mutable state from leaking across parent runs.

## Implemented Architecture

### Graph IR

The graph layer is defined in [`./agentcore/include/agentcore/graph/graph_ir.h`](./agentcore/include/agentcore/graph/graph_ir.h). `GraphDefinition` holds nodes, edges, lookup tables, compiled routes, and compiled knowledge-subscription indexes.

Node kinds currently include:

- `Compute`
- `Control`
- `Tool`
- `Model`
- `Aggregate`
- `Human`
- `Subgraph`

Node policies include flags for:

- fan-out
- stop-after-node
- join-on-incoming-branches
- join-scope creation
- knowledge-graph-reactive execution

Subgraph composition is part of the graph layer through `SubgraphBinding`, and the helper surface for validating and namespacing subgraphs lives in [`./agentcore/include/agentcore/graph/composition/subgraph.h`](./agentcore/include/agentcore/graph/composition/subgraph.h). `SubgraphBinding` also carries persistent-session metadata through `session_mode` and `session_id_source_key`, which is what lets one child graph definition be reused across many isolated child sessions.

### State

The state layer is defined in [`./agentcore/include/agentcore/state/state_store.h`](./agentcore/include/agentcore/state/state_store.h). It provides:

- `WorkflowState` for indexed typed fields
- `BlobStore` for larger payloads
- `PatchLog` for incremental mutation history
- `StringInterner` for stable interned string identifiers
- `KnowledgeGraphStore` for entity/triple storage
- `TaskJournal` for persisted once-only side-effect outcomes

`Value` is a small tagged union defined in [`./agentcore/include/agentcore/core/types.h`](./agentcore/include/agentcore/core/types.h), and supports:

- `std::monostate`
- `int64_t`
- `double`
- `bool`
- `BlobRef`
- `InternedStringId`

The knowledge-graph layer is defined in [`./agentcore/include/agentcore/state/knowledge_graph.h`](./agentcore/include/agentcore/state/knowledge_graph.h). It supports entity upserts, triple upserts, indexed lookup, matching by pattern, neighbor traversal, serialization, and copy-on-write shared backing checks.

This split exists because graph execution tends to mix two very different data profiles:

- compact control state such as counters, routing markers, and status flags
- larger artifacts such as prompts, model outputs, tool payloads, and serialized snapshots

Keeping those categories separate allows the engine to move small typed state through the step loop without repeatedly copying larger buffers.

The task journal exists for a narrower operational reason: some workflows need to perform synchronous external work inside a node body and still remain restart-safe. Rather than pushing idempotency policy into every node, the runtime exposes recorded-effect helpers on `ExecutionContext` and persists those outcomes in the state layer. That keeps effect commitment under the engine’s checkpoint/proof model instead of making replay behavior an ad hoc application concern.

### Execution

The execution layer is centered on `ExecutionEngine` in [`./agentcore/include/agentcore/execution/engine.h`](./agentcore/include/agentcore/execution/engine.h). The public surface includes:

- `start()`
- `step()`
- `run_to_completion()`
- `resume()`
- `resume_run()`
- `interrupt()`
- `apply_state_patch()`
- `inspect()`
- `register_graph()`
- checkpoint-policy configuration
- checkpoint storage selection and loading
- stream event reads

Checkpoints and traces are defined in [`./agentcore/include/agentcore/execution/checkpoint.h`](./agentcore/include/agentcore/execution/checkpoint.h). The implementation stores:

- lightweight checkpoint metadata for every recorded checkpoint
- optional full `RunSnapshot` payloads for resumable checkpoints
- append-only trace events
- optional persisted checkpoint records through pluggable storage backends

The current storage backends are:

- binary file persistence
- SQLite-backed persistence when the build is configured with SQLite support

Proof digests are available in [`./agentcore/include/agentcore/execution/proof.h`](./agentcore/include/agentcore/execution/proof.h). The current proof surface computes digests over snapshots and trace sequences.

Public streaming is defined in [`./agentcore/include/agentcore/execution/streaming/public_stream.h`](./agentcore/include/agentcore/execution/streaming/public_stream.h). Stream events carry:

- run, graph, node, branch, and checkpoint identifiers
- node status and confidence
- patch counts and flags
- namespace frames for subgraph-aware event paths
- `session_id` and `session_revision` for persistent child sessions

This shape is deliberate: traces are append-only for observability, checkpoints are resumable when snapshot payloads are present, and public stream events are derived from trace data rather than maintained as a second independent event system.

### Persistent Subgraph Sessions

Persistent subgraph sessions are implemented in the dedicated subgraph execution seam under [`./agentcore/include/agentcore/execution/subgraph/session_runtime.h`](./agentcore/include/agentcore/execution/subgraph/session_runtime.h) and [`./agentcore/src/execution/subgraph/session_runtime.cpp`](./agentcore/src/execution/subgraph/session_runtime.cpp).

The runtime uses isolated committed child snapshots rather than shared mutable child state. The reason is practical:

- a persistent session can be restored deterministically from its last committed child snapshot
- current parent inputs can be overlaid onto that child state before execution
- successful child completion can commit one full child snapshot revision
- failure, cancellation, or waiting can leave the last committed child snapshot untouched

This is also how the runtime keeps knowledge-graph behavior explicit. Ephemeral subgraphs can receive a per-invocation knowledge-graph fork when propagation is enabled. Persistent sessions seed their child-local knowledge graph once on creation and then continue from their committed child-local graph on later invocations. Parent and child knowledge graphs do not auto-merge outside explicit bindings.

### Runtime And Scheduling

The runtime layer contains node execution interfaces, async handling, registries, and scheduling. The scheduler surface is defined in [`./agentcore/include/agentcore/runtime/scheduler.h`](./agentcore/include/agentcore/runtime/scheduler.h).

The current scheduler is composed of:

- `WorkQueue` for ordered runnable tasks
- `WorkerPool` for batched parallel execution
- `AsyncCompletionQueue` for tool/model completion promotion

`Scheduler` exposes ready-queue operations, async waiter registration, completion signaling, and parallel batch execution.

The reason this is split from the engine is to preserve a clean distinction between:

- execution semantics: what a node result means
- execution policy: when and where work runs

That distinction matters once the runtime supports fan-out, joins, async external calls, and subgraph execution, because it prevents concurrency concerns from leaking into node logic or state-commit logic.

### Adapters

The runtime uses registries rather than special-casing tools and models inside the engine. The public request/response types live in:

- [`./agentcore/include/agentcore/runtime/tool_api.h`](./agentcore/include/agentcore/runtime/tool_api.h)
- [`./agentcore/include/agentcore/runtime/model_api.h`](./agentcore/include/agentcore/runtime/model_api.h)

Built-in adapters currently include:

- HTTP tool adapter
- HTTP JSON tool adapter
- SQLite-style tool adapter
- local model adapter
- HTTP LLM adapter
- OpenAI-compatible chat model adapter
- xAI Grok chat model adapter
- Gemini `generateContent` model adapter

Those implementations live under `./agentcore/adapters/`.

The adapter boundary is intentionally narrow so that model/tool payloads can move as `BlobRef` values through the state system and execution engine without introducing engine-specific logic for individual external systems. That same constraint is why the current provider adapters split the way they do: Grok reuses the shared chat-completions HTTP seam because the request/response shape is compatible, while Gemini is implemented as a direct `generateContent` adapter so the runtime can expose its API-key auth and JSON-schema response path without pretending every provider speaks the same protocol.

The registries now also carry an explicit adapter contract through `AdapterMetadata`, transport/auth enums, capability flags, and stable error categorization helpers. That means adapters are no longer just callable handlers; they can describe:

- provider and implementation identity
- transport kind and auth expectations
- request and response formats
- sync/async, structured I/O, checkpoint-safe, JSON-schema, and SQL capabilities
- stable failure categories derived from tool/model response flags

This is the foundation for the next layer of work: richer provider adapters and higher-level Python ergonomics built on top of a discoverable runtime contract rather than ad hoc handler conventions.

### Python Binding Surface

The Python package under `./python/agentcore` is a compact builder and orchestration layer over the native runtime. The low-level graph surface still centers on `StateGraph`, but the package now also includes optional higher-level builders for common workflow shapes under `./python/agentcore/patterns`. Python callbacks may opt into a third `runtime` argument when they need access to native execution services that should stay coupled to the engine rather than reimplemented in Python.

The first exposed service in that seam is recorded once-only synchronous work through `RuntimeContext.record_once(...)` and `RuntimeContext.record_once_with_metadata(...)`. The motivation is operational rather than stylistic: if a callback performs synchronous work that must remain restart-safe, the outcome should be committed through the same native patch/checkpoint path as the rest of the run state. That keeps replay behavior explicit and verifiable instead of depending on ad hoc Python-side memoization.

## Repository Layout

All directories below are relative to the repository root (`./`).

The repository is organized by subsystem rather than by executable:

- `./agentcore/include/agentcore/core`: common runtime types
- `./agentcore/include/agentcore/graph`: graph IR and subgraph composition metadata
- `./agentcore/include/agentcore/state`: workflow state, blobs, patch logs, knowledge graph
- `./agentcore/include/agentcore/state/journal`: persisted task/outcome journal types
- `./agentcore/include/agentcore/runtime`: scheduler, node runtime, async APIs, adapter registries
- `./agentcore/include/agentcore/execution`: engine, checkpoints, proofs, streaming
- `./agentcore/include/agentcore/execution/subgraph`: subgraph execution and session-lifecycle helpers
- `./agentcore/src/graph`: graph compilation and subgraph helpers
- `./agentcore/src/state`: state and knowledge-graph implementations
- `./agentcore/src/runtime`: scheduler, registries, async executor
- `./agentcore/src/execution`: engine, checkpointing, proof, streaming, and higher-level execution seams
- `./agentcore/src/execution/subgraph`: subgraph runtime and persistent-session orchestration
- `./agentcore/src/bindings/python`: CPython bridge and module surface
- `./agentcore/adapters`: concrete tool/model adapters
- `./agentcore/benchmarks`: native benchmark entry points
- `./agentcore/examples`: example programs
- `./agentcore/tests`: module and integration tests
- `./docs`: quickstarts, concepts, reference, and validation guides
- `./python/agentcore`: pure-Python package surface layered over the native module
- `./python/tests`: Python smoke and workflow validation
- `./python/benchmarks`: Python benchmark entry points
- `./cmake`: package configuration templates
- `./packaging`: packaging and consumer smoke material

This layout is meant to keep the dependency direction obvious: graph and state are lower-level, runtime and execution build on top of them, and bindings/adapters sit at the boundary.

## Build

```bash
cmake -S . -B build
cmake --build build -j
ctest --test-dir build --output-on-failure
```

The exported CMake targets are:

- `agentcore::graph`
- `agentcore::state`
- `agentcore::runtime`
- `agentcore::execution`
- `agentcore::adapters`
- `agentcore::agentcore`

The root project name is `agentcore`, and the package configuration is generated through `./cmake/agentcoreConfig.cmake.in`.

## Python Package

The repository also builds a pip-installable wheel through [`./pyproject.toml`](./pyproject.toml). The published distribution name is `agentcore-graph`, while the Python import package remains `agentcore`. The wheel packages the Python API, the native extension, and the compatibility namespace under `agentcore_langgraph_native`.

The simplest way to use AgentCore from Python is to install it directly from PyPI:

```bash
python3 -m pip install agentcore-graph
```

Build the wheel from the repository root:

```bash
CC=cc CXX=c++ python3 -m pip wheel . -w dist
```

Install the built wheel into an isolated target:

```bash
python3 -m pip install --target /tmp/agentcore-wheel-test dist/agentcore_graph-*.whl
PYTHONPATH=/tmp/agentcore-wheel-test python3 -c "from agentcore.graph import StateGraph; print('ok')"
```

The wheel is intentionally focused on the Python runtime surface. It does not publish the top-level `langgraph` shim package, which avoids colliding with an existing upstream `langgraph` installation while still exposing the compatibility layer through `agentcore_langgraph_native.langgraph_compat`.

The repository now also includes release automation under [`.github/workflows/wheels.yml`](./.github/workflows/wheels.yml) and [`.github/workflows/publish-pypi.yml`](./.github/workflows/publish-pypi.yml). The current wheel matrix is Linux `x86_64`, CPython 3.9-3.12, built against `manylinux_2_28` so the published wheels are broadly installable on modern glibc-based Linux systems while source installs remain available as a fallback.

## C++ Usage

The basic execution flow is:

1. construct a `GraphDefinition`
2. bind and sort edges
3. start a run with `ExecutionEngine::start()`
4. drive the run with `step()` or `run_to_completion()`
5. inspect state, checkpoints, traces, and stream events

```cpp
#include "agentcore/execution/engine.h"
#include "agentcore/graph/graph_ir.h"

using namespace agentcore;

enum DemoStateKey : StateKey {
    kMessage = 0
};

NodeResult write_message(ExecutionContext& context) {
    StatePatch patch;
    patch.updates.push_back(FieldUpdate{
        kMessage,
        context.blobs.append_string("hello")
    });
    return NodeResult::success(std::move(patch), 1.0F);
}

NodeResult stop_node(ExecutionContext&) {
    return NodeResult::success();
}

int main() {
    GraphDefinition graph;
    graph.id = 1;
    graph.name = "demo";
    graph.entry = 1;
    graph.nodes = {
        NodeDefinition{1, NodeKind::Compute, "write_message", 0U, 0U, 0U, write_message, {}},
        NodeDefinition{
            2,
            NodeKind::Control,
            "stop",
            node_policy_mask(NodePolicyFlag::StopAfterNode),
            0U,
            0U,
            stop_node,
            {}
        }
    };
    graph.edges = {
        EdgeDefinition{1, 1, 2, EdgeKind::OnSuccess, nullptr, 100U}
    };
    graph.bind_outgoing_edges(1, std::vector<EdgeId>{1});
    graph.sort_edges_by_priority();

    ExecutionEngine engine(2);
    RunId run_id = engine.start(graph, InputEnvelope{1U});
    RunResult result = engine.run_to_completion(run_id);
    (void)run_id;
    (void)result;
}
```

Examples in [`./agentcore/examples/planner_executor_graph.cpp`](./agentcore/examples/planner_executor_graph.cpp), [`./agentcore/examples/retrieval_graph.cpp`](./agentcore/examples/retrieval_graph.cpp), [`./agentcore/examples/knowledge_graph_workflow.cpp`](./agentcore/examples/knowledge_graph_workflow.cpp), and [`./agentcore/examples/runtime_proof_suite.cpp`](./agentcore/examples/runtime_proof_suite.cpp) exercise planner/executor flow, retrieval, knowledge-graph state, and proof/checkpoint behavior.

## Python API

When `AGENTCORE_BUILD_PYTHON_BINDINGS=ON`, the build emits a package under `./build/python/agentcore`.

The current Python surface is implemented in [`./python/agentcore/graph/state.py`](./python/agentcore/graph/state.py) and exposes:

- `StateGraph`
- `CompiledStateGraph`
- `START`
- `END`
- `Command`
- `RuntimeContext`
- `ToolRegistryView`
- `ModelRegistryView`
- `PipelineGraph`
- `PipelineStep`
- `SpecialistTeam`
- `Specialist`

The graph builder currently provides:

- `add_node()`
- `add_edge()`
- `add_conditional_edges()`
- `add_fanout()`
- `add_join()`
- `add_subgraph()`
- `set_entry_point()`
- `compile()`

For users who want a more declarative Python surface without giving up the native execution path, the optional pattern layer under [`./python/agentcore/patterns`](./python/agentcore/patterns) adds:

- `PipelineGraph` for sequential stage pipelines
- `SpecialistTeam` for dispatch/fan-out/aggregate specialist workflows backed by persistent child-session subgraphs

Those helpers still compile into the same native `StateGraph` runtime underneath. The goal is to remove repetitive wiring for common orchestration shapes without introducing a second execution model beside the native core.

The compiled graph object provides:

- `invoke()`
- `invoke_with_metadata()`
- `invoke_until_pause_with_metadata()`
- `resume_with_metadata()`
- `stream()`
- `ainvoke()`
- `ainvoke_with_metadata()`
- `astream()`
- `batch()`
- `abatch()`
- `.tools`
- `.models`

Python callbacks may currently accept:

- `state`
- `(state, config)`
- `(state, config, runtime)`

Example:

```python
from agentcore.graph import END, START, StateGraph


def step(state, config):
    count = int(state.get("count", 0)) + 1
    return {"count": count}


def route(state, config):
    return END if state["count"] >= 3 else "step"


graph = StateGraph(dict, name="counter", worker_count=2)
graph.add_node("step", step)
graph.add_edge(START, "step")
graph.add_conditional_edges("step", route, {END: END, "step": "step"})

compiled = graph.compile()
final_state = compiled.invoke({"count": 0})
metadata = compiled.invoke_with_metadata({"count": 0})
```

The Python layer focuses on a compact builder surface backed by the native runtime rather than mirroring the entire internal C++ API. The reason is to keep the Python entry point predictable while execution, scheduling, checkpointing, streaming, joins, and subgraph behavior stay in native code.

When a callback accepts a third positional argument, the runtime passes a `RuntimeContext`. The current Python-facing helper surface is intentionally small:

- `runtime.available`
- `runtime.record_once(key, request, producer)`
- `runtime.record_once_with_metadata(key, request, producer)`
- `runtime.invoke_tool(name, request, decode="auto")`
- `runtime.invoke_tool_with_metadata(name, request, decode="auto")`
- `runtime.invoke_model(name, prompt, schema=None, max_tokens=0, decode="auto")`
- `runtime.invoke_model_with_metadata(name, prompt, schema=None, max_tokens=0, decode="auto")`

That seam exists for restart-safe synchronous work. If a Python node needs to compute or fetch a value once and then replay the committed outcome on later visits within the same run, the runtime helper routes that through the native task journal rather than asking application code to invent its own replay policy.

Compiled graphs also expose graph-owned adapter registries directly through `.tools` and `.models`. That lets Python code register built-in adapters such as the SQLite-like tool adapter, the HTTP JSON tool adapter, the local model adapter, the OpenAI-compatible chat model adapter, the xAI Grok chat model adapter, and the Gemini `generateContent` model adapter without dropping into C++. The same registry views now also accept custom Python-backed tool/model handlers through `compiled.tools.register(...)` and `compiled.models.register(...)`, with optional payload decoding and metadata overrides. The important part is where those handlers land: they are still registered into the native graph-owned registries, so direct invocation, `RuntimeContext` invocation, registry inspection, and subgraph inheritance all go through the same runtime-owned adapter path rather than a separate Python-only dispatch layer.

Subgraph notes:

- Python-defined subgraphs are compiled into native `Subgraph` nodes rather than being interpreted in Python.
- Subgraph stream events carry namespace frames so parent and child execution paths can be distinguished in one trace.
- `add_subgraph(..., session_mode="persistent", session_id_from="field_name")` enables persistent child-session reuse keyed by a parent field.
- Stream and metadata events expose `session_id` and `session_revision` for persistent child sessions.
- `Command(wait=True)` together with `invoke_until_pause_with_metadata(...)` and `resume_with_metadata(...)` exposes a minimal Python pause/resume seam over the native checkpoint model.
- If a graph uses `add_subgraph(...)`, the supplied `config` must be pickle-serializable so the runtime can propagate it into child runs and nested subgraphs.

## Validation And Benchmarks

The repository contains both module tests and end-to-end runtime checks. The default validation path is:

```bash
cmake -S . -B build -DAGENTCORE_BUILD_PYTHON_BINDINGS=ON -DAGENTCORE_BUILD_BENCHMARKS=ON
cmake --build build -j
ctest --test-dir build --output-on-failure
```

Additional runnable entry points include:

- `./build/agentcore_runtime_benchmark`
- `./build/agentcore_persistent_subgraph_session_benchmark`
- `PYTHONPATH=./build/python python3 ./python/tests/state_graph_api_smoke.py`
- `PYTHONPATH=./build/python python3 ./python/tests/agent_workflows_smoke.py`
- `PYTHONPATH=./build/python python3 ./python/tests/patterns_smoke.py`
- `PYTHONPATH=./build/python python3 ./python/tests/adapters_runtime_smoke.py`
- `PYTHONPATH=./build/python python3 ./python/benchmarks/state_graph_api_benchmark.py`
- `python3 ./python/benchmarks/langgraph_head_to_head.py` after installing upstream `langgraph`

The native benchmark currently exercises:

- multi-worker execution
- routing hot-path behavior
- shared-state fork behavior
- reactive knowledge-graph frontier behavior
- queue indexing behavior
- recorded-effect hit/miss cost through the task journal
- subgraph and resumable-subgraph execution
- async multi-wait subgraph execution
- persistent-session fan-out across distinct child sessions
- direct-versus-resumed persistent-session replay validation

The Python benchmark currently exercises:

- synchronous invoke cost
- async invoke cost
- recorded-effect replay cost through the binding layer
- recorded-effect miss cost through the binding layer
- persistent-session fan-out with namespaced and session-tagged events
- pause/resume specialist flows with child-local memory and once-only effects

The optional comparison benchmark in [`./python/benchmarks/langgraph_head_to_head.py`](./python/benchmarks/langgraph_head_to_head.py) publishes a measured snapshot against upstream LangGraph and is summarized in [`./docs/comparisons/langgraph-head-to-head.md`](./docs/comparisons/langgraph-head-to-head.md).

The persistent-session native benchmark is also the replay-validation gate for this feature: it checks direct-versus-resumed output equality, proof-digest equality, committed-session counts, once-only producer counts, and namespaced/session-tagged event coverage. The Python benchmark mirrors those workloads through the binding layer, asserts final-state and session invariants, and emits the corresponding digests for inspection.

## Acknowledgements

AgentCore is an independent project. It is not affiliated with or endorsed by LangChain Inc.

I am grateful to several projects and ideas that helped clarify the design space for graph-based runtime systems:

- [LangGraph](https://github.com/langchain-ai/langgraph) and its [documentation](https://docs.langchain.com/langgraph) for helping make graph-oriented agent orchestration more concrete and widely accessible.
- [NetworkX](https://networkx.org/) for its clean graph-oriented modeling surface and for helping normalize graph-first APIs for developers.
- [Pregel](https://research.google/pubs/pregel-a-system-for-large-scale-graph-processing/) for the larger body of graph-processing ideas around deterministic superstep-style execution.
- [Apache Beam](https://beam.apache.org/) for durable dataflow concepts that continue to influence how many engineers think about structured execution, replay, and checkpointing.

The project also benefits from the broader systems community working on workflow runtimes, replayable execution, state machines, and graph processing.

## License

This repository includes a root [`./LICENSE`](./LICENSE) and [`./NOTICE`](./NOTICE). 
