Intent - Describe a feature and AI agents build, verify, and ship it
by•
Intent is a developer workspace built for agent-driven development. Define a feature as a spec, and a team of agents coordinates the work (from implementation to verification) inside an isolated workspace with built-in code, terminal, and git.
Replies
ZeroHuman.
Excited to hunt Intent by Augment Code today.
Intent is a developer workspace where agents coordinate and execute work end-to-end.
This isn’t a coding assistant. It’s an agent-driven development system.
Instead of prompting one agent at a time, you define a spec and a coordinator breaks it into tasks, delegating to specialists (implement, verify, debug, review) running in parallel.
This adds up to:
• Specs that stay alive as work progresses
• Built-in verification loops, not just code generation
• A full workspace (editor, terminal, git)
If you’ve been exploring agentic dev but didn’t want to build the orchestration layer yourself , this is definitely worth a look.
Product Hunt
@curiouskitty Thanks for your question, it’s a good one.
Under the hood, Intent gives each task its own workspace backed by a git worktree + branch, so agents get an isolated checkout but share a single .git history for cheap branching and instant sync. The Coordinator turns your spec into a plan with explicit task dependencies, then runs specialist agents in waves: independent tasks in parallel, dependent ones after predecessors land, all staying aligned via a living spec that updates as work is done. On the back end, Intent has full git workflow built in (branching, commits, PRs, merge) plus auto-rebase/conflict surfacing, so you can stack or fan out branches without becoming the human traffic cop, you just review grouped changes per task/agent and ship.
This sounds cool, tell me, how I can trust on quality of this agent for work?
@avinashvagh1 Totally fair question. A few concrete reasons teams trust Intent here:
It runs on Augment Code, which is SOC 2 Type II and ISO/IEC 42001 certified, with public security docs (no NDA needed).
Your code is never used for training, and the architecture is non-extractable with a Proof-of-Possession API, so it can’t exfiltrate code or leak across tenants.
You keep control via CMEK, encryption in transit/at rest, and continuous third-party pen-testing.
On quality: Intent is spec-first, with a coordinator + specialist agents + verifier that work in isolated git worktrees, so every change shows up as normal diffs you can review like any PR.
Public refs if you want to dig deeper: Trust Center trust.augmentcode.com and Security & Privacy augmentcode.com/security .
Otto Radio
Wrote up a post on how our teams collaborate within Intent. We've been able to effectively eliminate the designer/developer handoff. More details on the process, screenshots, etc: https://lukew.com/ff/entry.asp?2148
How well does it handle larger, messy codebases in practice, where context and dependencies aren’t always clear?
@becky_gaskell Thanks for asking, this is exactly where Augment Code shines.
We’re built to handle very large, complex codebases: monorepos, legacy monoliths, and even “spaghetti” code with lots of cross-cutting dependencies. Under the hood, we use our own Context Engine rather than a basic “embed + vector search” stack, which lets us reason over millions of lines of code with much higher fidelity than typical RAG-style tools.
If you’re dealing with a big or messy codebase you are at the good place.
@tanner_beetge Yes. In Intent, agents are usually hierarchical, not a flat swarm:
A controller agent acts like a tech lead: it understands the main goal, breaks it into subtasks, runs specialist agents, and decides what to accept/merge.
Specialist agents do focused work (code, tests, analysis) and report back, they don’t “vote,” their outputs are checked against the shared spec + workspace + tests/CI, and the controller, the verifier agent (plus the human) has final say.
So they “value” each other’s work through this structure and verification, not by arguing as equal peers.
Running agents one at a time while keeping track of what each one did is exhausting as a solo dev. The coordinator layer is the thing that's been missing.
I like this. It seems very interesting. CLI code understanding and agent-driven development make a lot of sense. I'm just wondering, does it do any browser work? That's where most of my time currently gets sucked going back to the browser and seeing if everything has been implemented okay. I think that would be a great problem to tackle anyways. Love the product, and we'll give it a try. Best of luck.
@bitsandtea We know the pain of switching back and forth between your workspace and browser. That’s why we’ve made it very easy to integrate third-party tools like Playwright. With a simple installation, agents can navigate your app in real time to see if changes worked or if there are any regressions.
You can also use the integrated browser directly in Intent, so you can stay on the same page and handle both coding and testing together.
The code editor is really a great concept because I do have to maintain a separate workspace just for the nodes. And I hope it has voice-to-text built-in.
@nayan_surya98 Thanks for the comment, it is really appreciated. We will follow up with the product team about your suggestion.
Open Wearables
the isolated workspace approach is smart. removes the "works on my machine" problem entirely when agents are doing the building. how do you handle dependencies that need specific system configs or external APIs during the build process?
@piotreksedzik In Intent, each workspace is an isolated git worktree + its own shell environment, so you treat it like a real dev box: you (or your team) define per-repo setup commands that run when a workspace spins up (e.g., installing system deps, running npm install/poetry install, seeding local DBs, etc.).
Agents then build and run inside that configured environment, not a generic sandbox, so anything that depends on specific system packages, tools, or build steps is handled by your setup script rather than brittle per-agent hacks.
For external APIs and services, workspaces are just normal terminals: you can bring in your own .env/secrets, point agents at staging/prod endpoints, and even wire MCP integrations for tools like Jira, Sentry, etc... Agents call into those the same way a human would from that shell and browser surface.
So instead of trying to virtualize every possible system config inside the agent, Intent standardizes the workspace bootstrap: once the workspace’s setup script has created the right system env + API wiring, any agent you run there sees the same, reproducible environment, which is why the “works on my machine” problem goes away when agents are doing the building.