Running
Agents
Agent Identity Explorer
🏢
Experimental playground for agent routing and orchestration
Travis Muhlestein PRO
TravisMuhlestein
AI & ML interests
Product & AI CTO at GoDaddy focused on AI infrastructure, orchestration, agent systems, observability, and enterprise-scale AI deployment
Recent Activity
posted an update 3 days ago
As AI agents become more autonomous, identity becomes part of the infrastructure problem.
We’ve been working on Agent Name Service (ANS) to give agents a verifiable identity before they interact or exchange sensitive information.
One design goal is that verification shouldn’t depend on a centralized service for every request. ANS can verify an agent offline against published root keys, with the verification path completing in under 0.5 ms on a single server core.
The work builds on infrastructure we already have around domains and DNS.
We’re also looking at that infrastructure at the DNS layer through SVCB and HTTPS records, evolving how modern applications connect beyond traditional CNAME-based architectures.
Two engineering deep dives:
→ Don’t Trust. Verify. Offline, Sub-Millisecond Agent Verification with ANS
https://www.godaddy.com/resources/news/dont-trust-verify-offline-sub-millisecond-agent-verification-with-ans
→ Beyond CNAME Flattening
https://www.godaddy.com/resources/news/beyond-cname-flattening repliedto their post 28 days ago
One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end. posted an update 28 days ago
What happens when you treat an AI support assistant like a product instead of a chatbot?
The Katana platform team had 5 engineers supporting 500+ production applications, with adoption doubling every year.
They built an AI assistant grounded in:
Slack history
Internal documentation
Custom instructions
Live platform API data, including logs and configuration
Today, it resolves 80%+ of support requests autonomously.
The interesting part is what happens around the model.
The team continuously improves the assistant based on real usage, monitors escalations and sentiment, keeps it updated as the platform changes, and maintains a human fallback when needed.
They also ran a two-week experiment with direct Slack support disabled before making the approach permanent.
The model is only one piece of the system. Context, feedback loops, observability, escalation paths, and human handoff are what make it work in production.
🔗 https://www.godaddy.com/resources/news/how-we-scaled-platform-support-10x-without-scaling-the-team Organizations
