AI coding tools have been mainstream for a few years now, and "adopt AI" is the rallying cry. But most engineers still use AI the same way they did in 2023: write a one-line prompt, wait for Claude Code to figure it out and ship a patch, then start a fresh conversation for the next task. AI is in the loop, but tasks still go one at a time, and the human is the bottleneck.
Agent Native is one of the most hyped phrases of 2026, and everyone defines it differently. Our take: it's the shift from "built for humans" to "built for agents." Traditional software assumes a human interacting — clicking, filling forms, waiting, deciding. Agent Native assumes a program interacting — agents calling, judging, recovering, all on their own. The system has to be designed for that mode, not retrofitted with an API after the fact.
The InsForge platform itself is built around agent usage. Internally, we've also rebuilt our own engineering workflow the same way. Here are four layers of what that looks like.
Context Layer: Tell the Agent What It's Working On
Every front-end, back-end, and OSS repo has CLAUDE.md, AGENTS.md, and a set of custom skills. insforge-dev encodes our front- and back-end conventions. publish-blog handles blog publication. seo-frontmatter checks SEO fields. check-pr runs our PR review checklist. An agent picking up a task doesn't start from zero — it knows the project structure, the conventions, the release process, and the tools it can call. Output quality stays predictable.
Process Layer: Spec, Plan, Review
We adopted shared workflow frameworks like superpowers and gstack across the team. Any non-trivial request goes through a spec (what we're building, what we're not), a plan (broken into verifiable steps), and a cross-review by humans and other agents before implementation starts.
Every feature ships with documentation and test coverage. Every PR clears formatting, tests, SEO, and security checks before it merges. Once these rules live in skills and CI, agents enforce them on themselves. Humans stop reviewing the same trivial issues twice.
Parallel Layer: Sub-Agents and Worktrees
Most of the code is written by AI. Humans mostly make decisions. So during implementation we fan out sub-agents into parallel git worktrees — one changing schema, one writing the front-end, one filling in e2e tests. Human attention shifts from "wait for this PR to finish" to "what's the next decision," which removes the serial bottleneck.
Automation Layer: Hand Off the Workflows
We built internal agents for the workflows that recur:
- Log scanner: sweeps PostHog and server logs on a schedule, cross-references suspicious activity with the code, and files issues.
- Issue handler: picks up an issue, designs a fix, implements it, tests it, opens a PR.
- PR reviewer: uses
ghand review tooling to comment on PRs until they meet our bar. - Release agent: drives CI/CD through version cuts and deployment.
Platform-level troubleshooting knowledge — common stats queries, incident investigation, performance analysis — is encoded as skills too. A natural-language ask is enough to kick off the whole flow.
What This Means for the Platform
Going through this loop reinforced our product thesis: InsForge has to be designed for agents from the ground up. Backend branching lets an agent test schema changes in an isolated environment without touching prod. Skills + CLI exposes the entire platform — knowledge and operations — to agents, so they never need to log in to the dashboard. Critical-path errors return a nextAction hint so the agent can route itself to the right next step instead of stalling on a stack trace.
Make things easy for the agent, and you've made things easy for the developer. That's where platform value lives in the AI era.