Abhijeet Bhagat

API documentation is often treated as a follow-up task after endpoints ship. In practice, that delay creates support overhead, slows onboarding, and increases integration mistakes. Developers need one place where they can see available endpoints, required parameters, expected responses, and error behavior. When that information is missing or not up-to-date, teams spend time reverse-engineering requests from code examples or trial and error.

Adding API docs early creates a shared reference for product, backend, frontend, and partner teams. It improves handoffs during development, and it reduces the gap between what an API is intended to do and what external users think it does. Good docs also improve operational reliability because they make edge cases visible before production traffic hits them.

This is the era of AI dominance and almost every app on the internet has some or the other use case fulfilled by AI. A common intention nowadays is to integrate AI with documentation to enable users learn about the app and its features. But what about integrating AI to help users execute actions on the app?

This is what we are excited to announce with Enscribe Ask AI chat agent. Let's dive into what it looks like and how it works.

The agentic AI chat​

You will see the Ask AI as the first menu item in the left sidebar.

Clicking on it will open the AI chat page.

You can ask practical ENS questions, such as:

• what a primary name is
• how reverse resolution works
• how to name contracts from a CSV.

You can also ask the agent to name your contract on a particular chain or give it a csv containing multiple contracts to name and it will do the rest.

Here's what it looks like when you ask the agent to name a contract on a particular chain:

Clicking on the "Yes, Sign Transactions" button will open the connect wallet to approve the transactions.

And here's what it looks like when you ask the agent to name multiple contracts from a CSV:

You can either drag and drop the CSV file in the chat box or click on the "+" button to upload it.

We'll now see how the AI agent is designed to help you execute ENS workflows.

Technical architecture overview​

At a high level, Enscribe AI chat has three layers:

1. AI chat page: This is where users ask ENS questions, upload a CSV for batch naming, and review next steps.
2. Decision layer (OpenAI intent API): The model decides whether to answer directly or route the request into an execution flow.
3. Execution layer (MCP server): For action requests, MCP runs the ENS workflow: checks prerequisites, prepares transactions, tracks progress, and verifies outcomes.

That structure keeps the experience simple for users. You can ask, “What is a primary name?” and get a clear answer. You can also ask, “Name all contracts in this CSV on Sepolia,” and move into a guided transaction flow.

For naming flows, we keep safety steps in the loop: deterministic CSV validation, explicit approval before signing, status tracking, and operator access revocation after execution, including cleanup paths when something fails.

We also have extended the MCP server with Namespace's ens-mcp server to support more ENS workflows, such as:

• Who owns vitalik.eth?
• What ENS names are owned by 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045?

Getting agentic​

Users are becoming more familiar with AI and interact with it using languages that we speak. We are building Enscribe AI chat to help users execute ENS workflows with prompts.

We are constantly working on improving the agent to support more ENS workflows and make it even more easier for users to name their contracts on ENS.

You can try it out on the Enscribe App.

Happy naming! 🚀

After a good kickoff last month, we’re back for our second monthly community sync. We’ve been busy incorporating feedback from the first call, and we have significant updates to share across the Enscribe ecosystem.

In our recent guide on smart contract versioning, we explored how smart contracts can be versioned and suggested a few ideas on how to integrate contract versioning in your existing deployment pipelines. This post is a sequel explaining how similar ideas can be applied when you have upgradeable contracts.

We’ve spent the last few months focused entirely on the technical side of Enscribe building out the web app and tools for Foundry and Hardhat to make ENS integration for smart contracts less of a headache.

But we don't want to build in isolation. Smart contract identity is complex and the best way to build and improve tools for it is to actually talk to the people who are interacting with naming contracts every day.

In software engineering, versioning is a core tenet of release management. However, when smart contracts are deployed to Ethereum networks, the deployment artifacts live as 42-character hexadecimal strings, with no onchain versioning information being captured about them.

Foundry is one of the most popular toolchains for Ethereum smart contract development. Built in Rust, Foundry provides everything needed to build, test, and deploy smart contracts. At the center of this workflow is Forge, Foundry’s scripting and deployment tool. Forge scripts are written in Solidity itself, allowing developers to deploy contracts and interact with them.

Basenames are growing in popularity. Users set them for their EOA accounts so that they don’t have to use hex addresses when interacting on Base. Basenames use the solid ENS infra underneath and are fully ENSIP-19 compliant.

We created the Enscribe App to make it as simple as possible for teams to name their smart contracts. However, this approach is not always compatible with naming DAO contracts.