Morphable, AI-First SDK – State of the Art
Malleable and Self-Generating Software Systems
A core vision for the AMAI SDK is software that can modify and extend itself autonomously. Early examples of this idea include Viv (now Samsung’s Bixby), an AI assistant that could dynamically generate its own code. Viv’s “self-generating software” allowed it to write new functions to accomplish tasks and compose plans on the fly medium.com. In modern research, LLM-driven agents are demonstrating self-improvement. For instance, a recent “Self-Improving Coding Agent” showed that an AI agent can iteratively edit its own source code to boost performance on coding tasks arxiv.org. Another project, Gödel Agent, takes inspiration from Gödel machines to enable an agent to recursively improve its own logic without fixed routines – it uses an LLM to modify its behavior based only on high-level goals arxiv.orgarxiv.org.
Meanwhile, techniques for on-the-fly skill generation have advanced rapidly. DynaSaur (2024), from UMD and Adobe, is an LLM agent framework that doesn’t rely on a fixed toolset – instead, it dynamically writes new “actions” as code in a general-purpose language and accumulates them for reuse arxiv.orgarxiv.org. This allows the agent to handle unforeseen tasks by effectively creating new API calls or tools when needed. Similarly, Voyager (2023) demonstrated an open-ended learning agent in Minecraft that uses GPT-4 to continuously generate and refine code “skills.” Voyager builds an ever-growing library of code to handle new challenges, leveraging feedback from the game environment (including errors) to improve its programs arxiv.org. These cutting-edge approaches to self-writing software show that “morphable” systems – which evolve by rewriting parts of themselves – are becoming feasible. The AMAI SDK can draw on these ideas to enable modules that adapt based on usage, data, or external feedback, effectively reprogramming themselves to meet new demands.
Autonomous API Generation and LLM Toolkits
To wrap legacy software into AI-consumable layers, the SDK will need to automatically interface with existing systems. One emerging standard here is MCP (Model Context Protocol) – an “AI-native” protocol for connecting LLMs with tools and services. MCP defines a communication format enabling an LLM client to invoke functions on a server in a structured way jingdongsun.medium.com. Notably, Anthropic’s Claude and other tools support MCP to let AI models call external APIs safely. By introspecting a legacy system’s capabilities (APIs, databases, etc.) and exposing them via a protocol like MCP or OpenAI’s function-calling schema, AMAI could let LLMs auto-discover and use legacy functionalities. For example, OpenAI’s plugin mechanism and function calling allow an LLM to call an API if given its spec, essentially turning a REST API into a “tool” the AI can use. Research from Meta on Toolformer likewise showed that an LLM can be fine-tuned to insert API calls into its output, learning when to use a tool on its own medium.com.
Platform toolkits are emerging to simplify this bridging. Fixie is one such platform where developers can easily create “agents” that connect an LLM to an external system. In Fixie, an agent is defined with some English instructions and a bit of code, and the platform hosts it as a service. The LLM is taught via few-shot examples how to call the provided code function for queries medium.commedium.com. For instance, a stock-price agent might include a quote() function (calling a finance API) and example prompts showing the LLM how to ask for Func[quote] when needed medium.commedium.com. The Fixie SDK wraps this into a cloud service that accepts natural language, routes it through the LLM, and executes the tool call, returning a formatted answer medium.com. Crucially, such agents can be packaged and shared – Fixie enables developers to contribute agents that extend the platform’s capabilities over time medium.com. This hints at a marketplace of AI tools, a concept the AMAI SDK could adopt (with decentralization).
Other frameworks like LangChain provide abstractions to turn any Python or TypeScript function into an LLM-accessible tool and chain these together. These toolkits still usually require manual definition of the interface, but upcoming systems aim to automate more of this. We see “autonomous API generation” in projects like Microsoft’s HuggingGPT, where ChatGPT orchestrates calls to many AI models by parsing a user request and deciding which model/API to invoke medium.com. In essence, HuggingGPT treats each ML model as a tool and the LLM as a dispatcher – a design that could extend to legacy software APIs as well. For a morphable SDK, the goal would be to analyze a legacy app’s UI or code, infer its capabilities, and spawn an API adapter (REST, GraphQL, etc.) with minimal human effort. Some early strides here include using LLMs to read docs or UIs and generate API bindings or RPA scripts. By combining these approaches, AMAI could automatically wrap old systems (think COBOL programs or on-prem databases) into modern AI-driven microservices that any agent can call. This automation lowers the barrier to integrating with “everything,” allowing the SDK’s toolset to grow dynamically.
Event-Driven LLM Orchestrators and Self-Reflexive Agents
Achieving true autonomy will require orchestration frameworks that can handle events, long-lived sessions, and feedback loops. Traditional prompt-chaining (as in basic LangChain agents) executes a fixed loop of “LLM → tool → LLM,” which can be limiting. New frameworks like LangGraph extend this by letting developers define graphs of LLM calls and tools with conditional logic and even cycles. LangGraph allows agents to loop back on themselves or branch, enabling more flexible, non-linear workflows medium.commedium.com. It introduces the notion of stateful graphs, so an agent can maintain memory across steps and make decisions based on prior outputs medium.commedium.com. Importantly, LangGraph supports event streaming and real-time feedback: as tools produce intermediate results or as the LLM generates tokens, these events can be streamed and observed langchain-ai.github.iolangchain-ai.github.io. This event-driven approach means the AI runtime can react to partial results (or errors) by adjusting its course – a prerequisite for auto-reflexive behavior.
In addition to frameworks, research on agent self-reflection is influencing design. Techniques like ReAct, Reflexion, and Tree-of-Thoughts give agents the ability to reflect on intermediate outputs and revise their approach. For example, the Reflexion method has an agent generate a “thought” about what went wrong after a failed attempt, then try again – leading to significantly higher success rates in decision-making tasks arxiv.orgarxiv.org. Self-correcting loops are also evident in Voyager (mentioned earlier) and in academic works like MetaGPT or GRACE, where multiple LLM “experts” validate and critique each other’s solutions. The AMAI SDK can integrate these patterns so that generated tools or plans are not static – an agent can evaluate the outcome of a tool invocation (did the legacy system return the expected data?) and then adjust its strategy. Event hooks and an auto-reflexive runtime (one that can rewrite its plan at runtime) go hand-in-hand.
A concrete example of an event-driven, reflexive architecture is LangGraph Studio’s agent IDE, which allows pausing execution, inspecting state, and even injecting corrections mid-run langchain-ai.github.iolangchain-ai.github.io. This kind of tooling could be adapted for an autonomous setting: the agent itself, rather than a human, would inspect its state for anomalies or unmet goals and then modify its own workflow graph. Another example is AutoGPT (an open-source project that loops an LLM with a task list until completion) – it demonstrated the appetite for agents that can set new sub-goals on the fly and recover from mistakes, even if early versions were brittle. Newer orchestrators explicitly incorporate feedback channels. For instance, Microsoft’s Autogen framework (2023) enables multiple agent instances to communicate and correct each other, and allows tool outputs to be fed back into prompt context for evaluation. All these developments point toward runtime-adaptive agents. The AMAI SDK will leverage event-driven design (triggers, streaming outputs, state checkpoints) combined with reflection techniques so that AI agents can learn from each action and continuously refine their own behavior without human intervention.
AI-Native Developer Environments and Platforms
Building an AI-first SDK requires rethinking the traditional software stack. Projects like Unbody have started to define the “AI-native” backend stack, often using a TypeScript-first approach for developer familiarity. Unbody is an open-source platform that combines everything needed for AI-centric apps – data ingestion (“Perception”), vector databases and storage (“Memory”), an LLM reasoning layer, and an action interface – into one coherent framework github.comgithub.com. In other words, it’s the “Supabase of the AI era,” where instead of just static schemas and CRUD APIs, you get embeddings, knowledge stores, and integrated agents out of the box github.comgithub.com. A key part of such stacks is a headless, modular architecture: Unbody exposes content via APIs/SDKs and even supports MCP for direct LLM integration, while behind the scenes it manages vector indexes, generative modules, and function-calling logic github.com. This aligns with AMAI’s vision of containerized deployments with no protobufs – using modern web APIs, serverless functions, and JSON for communication, developers can plug legacy systems into a unified AI layer.
On the deployment side, technologies like Modal exemplify how to package and scale AI-driven code without devops friction. Modal is a serverless cloud platform (with GPU support) where you can write a Python (or TypeScript) function and deploy it as a scalable API in one line medium.com. Under the hood it builds a container image and handles autoscaling, so developers focus only on code. For an SDK that generates new microservices on the fly (wrapping legacy systems), this kind of infrastructure is ideal – each generated “tool” could be a small container or function that the orchestrator calls. Modal’s approach (similar to AWS Lambda, but AI-optimized medium.com) means even ephemeral code written by an AI can be executed reliably at scale. We might see AMAI integrate with such container orchestration to deploy self-written modules immediately into a cluster or edge network. Containerization also eases versioning and sandboxing – critical if the SDK is morphable. Each evolution of a component can run in isolation, and if something fails, it can roll back to a prior container.
On the dev experience side, “LLM-native” IDEs and tools are emerging. We’ve seen LangGraph Studio for visual agent design, and there are editor plugins (like Cursor.ai or VSCode Copilot Labs) aimed at making prompt and function design interactive. Even new languages or DSLs are appearing – e.g. AI-DSL in SingularityNET, or Microsoft’s TypeChat which uses TypeScript type definitions to constrain LLM outputs to expected schemas. These tools treat the LLM as a first-class element of the development process, not an afterthought. For example, TypeChat lets you define a TypeScript interface and will ensure the LLM’s JSON output conforms to it, bridging static typing with AI flexibility. We can expect the AMAI SDK to provide a developer environment where one can seamlessly define an interface to a legacy system, and then let the AI produce the glue code, with immediate testing in a sandbox. The goal is a tight feedback loop: developers specify high-level goals or constraints, the AI suggests implementations (or writes them), and developers can debug or refine using live data. By leveraging modern, high-level languages (TypeScript/Python) and containerized runtimes, the SDK can remain highly extensible – even the SDK’s own components could be updated or swapped out by AI-generated ones over time.
Decentralized Agent Ecosystems and Cross-Chain Protocols
An AI-first SDK that is living and evolving benefits greatly from decentralization – both for resilience and community-driven growth. We’re seeing the rise of decentralized agent marketplaces where developers (or even the agents themselves) can publish services, and users or other agents can discover and utilize them. For example, SingularityNET has a blockchain-based AI marketplace that allows anyone to create, share, and monetize AI services. It’s pitched as the first decentralized AI network of this kind mugglehead.comappengine.ai. In practice, SingularityNET providers register AI algorithms which can be invoked via the network’s protocol, and consumers pay with crypto tokens. Extending this concept, the AMAI SDK could enable a market of pluggable AI tools – each tool encapsulating a legacy system function or a learned skill – that are indexed on a decentralized registry (for example, as NFTs or smart contracts representing the service endpoint). Users of the SDK might query this registry to find, say, “the highest-rated SAP-invoice-processing agent” or “an open-source plugin for Salesforce integration,” and then pull it into their agent’s toolset on demand. This is analogous to how human developers search npm or PyPI for libraries – here the AI agent can perform an autonomous search for the best “plugin” for its task.
Some projects are pushing even further: Olas Network (by Autonolas) recently launched the Mech Marketplace, a fully decentralized bazaar where AI agents can hire other agents autonomously siliconangle.com. In this model, if one agent lacks a certain skill, it can negotiate with another agent that offers it, all via on-chain payments and without human involvement siliconangle.comsiliconangle.com. Olas also introduced Pearl, an “agent app store” where humans can find agents and even co-own them via tokens siliconangle.com. This two-sided economy (Pearl for human-agent discovery, Mech for agent-agent collaboration) is exactly aligned with a vision of an SEO-like ranking for optimal implementations – except the “search engine” is on-chain reputation and usage stats. In such a scenario, the AMAI SDK wouldn’t just statically publish a tool; it would perhaps mint an NFT or register a smart contract for that tool. Agents could have on-chain identities (DIDs) and use governance tokens to rate or stake on the quality of tools. Over time, the best implementations float to the top by earning more usage or token rewards. This decentralized curation replaces a centralized app store ranking with an open, transparent metric (much like PageRank but for agent services).
From a technical perspective, enabling a decentralized SDK means tackling cross-chain and cross-platform interoperability. Agents running across different blockchains or legacy environments need to share state and trust. Technologies like blockchain bridges and DAO voting relays become relevant. We have real examples of cross-chain coordination – e.g., Uniswap’s governance uses message-passing bridges (Wormhole, Nomad, etc.) to propagate decisions from Ethereum mainnet to deployments on Polygon, BNB Chain, and others medium.commedium.com. Similarly, an AI agent network might use a bridge or oracle service (like Chainlink CCIP) to sync an agent’s “knowledge state” or model updates across chains. In the user’s AMAI design, there is mention of WALRUS – a decentralized model repository – anchoring model version hashes on-chain and even bridging updates to networks. This ensures that multiple agents on different chains can trust they are using the same model checkpoint. Zero-knowledge proofs could further allow agents to prove something about their state or computation to others without revealing sensitive data, enabling trust in a trustless environment.
In summary, the frontier of AI tools is moving toward decentralization: networks where agents (or their human creators) publish services, vote on improvements, and even interchange skills in a permissionless way. The AMAI SDK stands to benefit from these innovations by building in support for decentralized identities, on-chain registries of tools, and cross-chain communication. By packaging each “morphable” component as a container that’s not only deployable in cloud but also referenceable on a blockchain, the SDK can enable a true open marketplace for AI capabilities. An agent developed in one context could be discovered and reused in another, and its upgrades could be versioned immutably on-chain for transparency. DAO governance could even guide the evolution of popular SDK components – for example, the community could vote in an upgrade to a certain module if a better implementation emerges. This way, the SDK literally evolves based on user demand, fulfilling the vision of a living software ecosystem.
Sources: The analysis incorporated insights from recent papers and platforms including self-evolving agents (e.g. Gödel Agent arxiv.org), dynamic tool generation frameworks like DynaSaur arxiv.org, agent orchestration libraries (LangGraph medium.com), AI-native stacks (Unbody github.com), serverless AI infra (Modal medium.com), and decentralized agent networks (Olas/Autonolas siliconangle.com, SingularityNET mugglehead.com). These examples illustrate the state of the art that AMAI’s morphable, AI-first SDK can build upon. The convergence of self-writing software, LLM-driven orchestration, and decentralized deployment is creating fertile ground for an SDK that not only wraps legacy systems for AI, but continuously reinvents itself to meet the future.
Citations
Gödel Agent: A Self-Referential Framework for Agents Recursively Self-Improvement
DynaSaur \scalerel: Large Language Agents Beyond Predefined Actions
[2305.16291] Voyager: An Open-Ended Embodied Agent with Large Language Models
AI Agents and Automation: Model Context Protocol (MCP) and My ...
HuggingGPT: Solving Complex AI Tasks by Connecting LLMs to ...
Building AI agent systems with LangGraph | by Vishnu Sivan | The Pythoneers | Medium
Deploy your GenAi app and ML Models on Modal | serverless deployment | by Yogendra Manawat | Medium
SingularityNET constructs global supercomputer network for AGI ...
SingularityNET | Decentralized Marketplace for AI Algorithms, AI ...
Olas launches decentralized AI marketplace where AI agents can hire each other - SiliconANGLE
Cross Chain Governance — Part II. Introduction | by Praveen Surendran | Tokamak Network | Medium
All Sources
