Professional software developers are in the business of solving problems with code. We are individual contributors primarily judged based on our ability to merge changes into the main branch of a repository.

However, we are also evaluated on our ability to ship things that people can actually use and understand. This requires us to complete the chore of writing documentation. A task is at best parenthetical to the "real work" of merging code and at worst a soul-crushing experience that makes us want to quit our jobs.

I find it ironic that I am employed by a company that provides tools to make writing documentation easier, yet still find myself procrastinating and dreading the task. Mintlify Agent was born from our team's personal experience with this feeling and desire to never face it again.

There are two main ways to interact with coding agents, through a terminal or Slack. For this discussion, I am grouping tools like the Cursor and Copilot sidebars with terminal interfaces because they are used in development applications that function similarly.

Mintlify currently provides a CLI tool with a mint dev command that allows you to edit your docs locally and see a live preview before deploying. This offers a great foundation for a terminal-based coding agent and is something our customers already have installed and are familiar with.

Given this context, it is all the more interesting that we decided to build Mintlify Agent as a Slack app instead.

I love the feeling of taking my socks off after a long day at work. It signals that I am in a new mode where I can relax and unwind.

Closing my terminal or IDE once my code is merged provides a similar signal. It tells me that I am done with the coding portion of my task and can focus on other things. Opening my development environment again to write docs feels like putting my socks back on to do chores around the house. It is a grueling experience that I want to avoid.

Slack on the other hand is a program I keep open all day on both my laptop and phone. I use it for both work and personal communication so it feels more like a comfy pair of slippers than socks. Opening Slack does not trigger the same mentally draining switch that opening a terminal does.

Therefore it is the best place for a writing agent dedicated to documentation. I see my PR merge notification in Slack, open the conversation thread, mention @mintlify, and tell it to update the docs from the changes I just made.

The process feels natural and easy like sliding into slippers. I can do it on the elevator ride down from the office or while waiting in line for coffee.

Terminal agents are taking the software development community by storm. Tools like Claude Code, Opencode, Factory, and a half dozen others are accumulating tens of millions of dollars in funding and generating billions of tokens in usage.

The challenge is that these tools are Swiss Army knives, designed to handle everything from writing code to running tests to deploying applications. While this broad capability is powerful, it introduces significant complexity.

Terminal agents can technically update documentation using git diffs without issue. Yet based on our customer conversations, this isn't happening much in practice.

Our hypothesis is that terminal agents are too complex for the straightforward task of writing docs. When you factor in the cognitive overhead of context engineering to get the agent to behave correctly, most people find it's simply not worth the effort.

A quick prompt contrast

Terminal agent prompt:

Read PR #123. Ignore lockfiles. Update /docs/guides/feature-x.md with breaking changes and a migration note. Add a link from /docs/navigation.md under ‘Guides’. Title case headings, keep tables as Markdown. Create a PR with a preview link.

Slack agent message:

@mintlify update docs for PR #123—main changes: 1) Feature X adds Y, 2) Breaking change Z. Please add a migration note and link it from Guides.

In our context, an "agent" is a LLM that runs tools in a loop to accomplish a goal. Specifically, it calls tools to read and modify files with the objective to create a pull request that updates documentation based on the user's request.

It is always best to give an agent the smallest possible context it needs to do its job well. This is the principle of context engineering. We therefore carefully considered the minimum set of tools the agent would need and decided on the following set.

• Docs file ops: list, read, write, edit, delete — core CRUD for docs files.
• Cross-repo access: external_list, external_read, list_repositories, fetch_pull_request — docs often live alongside app code or across repos.
• Site structure: read_navigation — ensures new or edited pages slot into the IA correctly.
• Web context: web_fetch, web_search — pull in authoritative references or related context when needed.
• Workflow and comms: message_user, todowrite/todoread, review_ready — keep state across loops, nudge the user, and ship a ready-to-review PR.

todowrite is especially useful because it lets the agent keep track of multi-step work across loops. The agent may read a file, realize it needs to adjust navigation and images elsewhere, and then return to the original file without dropping context.

This all plugs into a simple trust loop of see → review → merge → repeat. Mintlify’s platform has preview deployments, so the agent can share a URL in Slack where you can see the PR’s changes live in your browser before merging. No local checkout needed.

Agentic automation is my personal favorite emerging pattern in software development. This approach combines LLMs with tools in a structured workflow to accomplish goals with minimal human intervention.

Here's how it works in practice. Consider a customer subscribed event in your system. When triggered, an agent workflow with research and messaging capabilities automatically runs. The agent first searches for the latest trends in the customer's industry, then crafts a personalized welcome email incorporating those findings. The result is fully personalized onboarding at scale through AI-driven sequential tool use.

Millions of users already build these automations daily on platforms like make.com, gumloop, zapier, and n8n. Both technical and non-technical users rely on these tools to create sophisticated sequential agents.

Building on this trend, we added a new Agent endpoint to our API specifically for documentation workflow automations. Picture a commit pushed to main event that triggers an agent to update docs based on code changes, or a new feature released webhook that automatically adds relevant documentation sections.

We are excited to see what our users build with this new capability!

When I joined Mintlify, I took on the responsibility of updating the weekly changelog and instantly regretted it. I found myself procrastinating and dreading the task every Friday afternoon.

Then we rolled out Mintlify Agent internally, and I haven't had to write a changelog entry since. I just mention @mintlify in Slack and tell it to update the changelog based on the changes I made that week. It creates a pull request and preview, I review, and merge.

This is a real interaction I had with the agent last week:

me: yo @mintlify, i just had to send this message to a customer. Put up a pull request to update the docs with this info.

Hi @{{ person from acme }}, we were able to look into this and noticed that layout shift with the sidenav snapping up and down only occurs on {{ docs.acme.com }}, while {{ acme.mintlify.app }} works fine.
Looking a bit deeper we detected that you are using AWS CloudFront as a reverse proxy.
To fix this, can you try adding the following behaviors in your CloudFront distribution's Behaviors tab. Please order them from most specific to least specific.

The first behavior is for serving static assets from /mintlify-assets/_next/static/*.

• Path pattern: /mintlify-assets/_next/static/*
• Cache policy: CachingOptimized
• Origin request policy: AllViewerExceptHostHeader

The second is the default (*) behavior, which handles HTML and app router navigation.

• Path pattern: * (this should be your default behavior)
• Cache policy: CachingDisabled (since RSC ?_rsc= payloads vary and shouldn't be cached)
• Origin request policy: AllViewerExceptHostHeader

Make sure the static assets behavior is listed above the default behavior in your CloudFront behaviors list, as CloudFront evaluates them in order. The second is the default (*) behavior, which handles HTML and app router navigation.

• Path pattern: * (this should be your default behavior)
• Cache policy: CachingDisabled (since RSC ?_rsc= payloads vary and shouldn't be cached)
• Origin request policy: AllViewerExceptHostHeader

Make sure the static assets behavior is listed above the default behavior in your CloudFront behaviors list, as CloudFront evaluates them in order.

mintlify: Sure! I've created a pull request updating the docs with that information. You can review it here on GitHub and see the changes live in the preview deployment at this link.

Everything looked good on the first try, so I hit merge and was done. No wasted time or dreaded chore. 10/10 would recommend to a friend.

If you're a Mintlify Pro+ customer, this feature is available under Products → Agent in your dashboard. Try it on your next pull request, and tell us what you think!

What kind of agentic capabilities should we add next? Ping @mintlify on X (formerly Twitter). We’ll prioritize by demand.