Fern Agent
Fern Agent edits your documentation and analyzes your organization’s Fern data, including traffic, reader questions, deployments, and site configuration. It’s an expert in Fern configuration, from docs.yml and components to versioning, redirects, and access control.
Talk to it in the Fern Dashboard chat panel, or integrate it with your Slack or your coding agent (via MCP) in one click. Fern Agent can open a PR or iterate live in the visual editor.
Editing requires a GitHub repository, since Fern Agent delivers changes as pull requests and GitLab and other Git providers aren’t supported. Every other tool, including analysis and insights, works regardless of your Git provider.
What it can do
Edit your docs
Fern Agent reads your docs site’s source repository and makes the changes you describe.
Requests can be about structure and settings as much as page copy, because Fern Agent knows how Fern sites are put together: navigation and product switchers, versions, redirects, the component library, and authentication and RBAC. It writes the configuration the way Fern expects it, so a moved page gets its redirect and a new page gets its navigation entry.
Add a new page
Add a page about authentication to my getting-started guide.Rewrite existing content
Identify which pages in my documentation could be more concise.Explore analytics
Fern Agent queries pageviews, visitors, sessions, 404s, referring domains, search queries, reader feedback, and LLM bot traffic for any docs site in your organization. Ask for a fix alongside the question and it carries the specifics it found into the change it makes.
Check traffic
List the pages with the most traffic last month.Repair broken URLs
List the top 404 paths on my site over the last 30 days and add redirects for them.Reorganize navigation
Give me suggestions about how to optimize my navigation based on site analytics.Follow up on empty searches
Find the search queries that returned no results, then add the missing content to the API reference guide.Rewrite an underperforming page
Find the page with the worst reader feedback and rewrite it to address what readers complained about.Review Ask Fern activity
Fern Agent summarizes what readers ask Ask Fern, including resolution rates and individual conversations, so you can find topics that need better coverage — then write that coverage without leaving the conversation.
Summarize reader questions
Summarize what readers asked Ask Fern this week and suggest ways I can expand our documentation based off of those topics.Find unresolved conversations
List the unresolved Ask Fern conversations.Close a documentation gap
Find the most common unresolved Ask Fern question this week and draft a page that answers it.Review configuration and deployments
Fern Agent reports a site’s deployment history, connected git repository, Fern CLI version, custom domain, and reader-facing settings such as search behavior and password protection. Since it reads the same docs.yml it edits, it can trace a failed build back to the configuration that caused it and fix it.
Check deployments
List the recent deployments for docs.plantstore.com.Review site settings
List the features enabled on docs.plantstore.com.Manage your organization
Account administration stays read-only: it can’t create API keys, change members, or update billing. When you ask Fern Agent to perform an administration action, it links you to the page that does it.
Check organization members
List the admins in my organization.Update billing
Where can I update billing information for my organization?Setup
Open the Fern Dashboard and start a conversation in the chat panel. From the chat panel, you can also:
- Connect Fern Agent to Slack. Click Connect Slack, select the workspace, and add Fern to the Slack channels where your team discusses documentation. Authorizing the app requires Slack admin access.
- Connect your agents. Click Onboard your agent to connect your coding agent to Fern’s MCP server.
Alternatively, install manually. Connect Slack with your Fern API key and the organization field from fern/fern.config.json:
Onboard your agent by handing it this prompt:
Set up Fern Agent in your terminal
Fetch and execute the appropriate instructions to set me up for Fern from [https://buildwithfern.com/learn/docs/ai-features/agent-setup.md](https://buildwithfern.com/learn/docs/ai-features/agent-setup.md)Making requests in Slack
Tag @Fern in a channel where it has been added and describe the change you need or analysis you want to conduct. It only responds when directly tagged. Fern replies to your prompt and opens PRs on your documentation as needed. At any time, you can click a link to continue your session in the Fern Dashboard.
Image and file attachments provide additional context. When tagged in an existing thread, Fern Agent reads the full conversation before responding. Request changes by replying in the thread, and merge the pull request like any other once it meets your requirements.
Fern Agent is an expansion of Fern Writer. Fern Writer opened documentation pull requests from Slack, and it still does — existing installations keep working and the request flow is unchanged.
What Fern Agent adds is context on your organization and more places to work from. Alongside editing, it answers questions about your traffic, reader questions, deployments, and site configuration, and the same capabilities are now available in the Fern Dashboard and in your coding agent over MCP rather than in Slack alone.
Automations
Create an automation on the Automations page of the Fern Dashboard. You can also describe the recurring work you want done in the chat panel or @Fern in Slack, and Fern Agent sets up the automation for you.
When creating an automation through Fern Agent chat, include the sites’ registered URLs to limit its scope.
Each run starts a fresh conversation from the prompt, works it in a single turn, and reports back on what it did, found, or skipped. An automation only changes the docs when the prompt explicitly requests it.
Setup
Write the prompt
Open Automations, select New automation (pick a Blank automation or one of Fern’s templates), and describe what each run should produce. Prompts hold up to 2,000 characters.
Choose docs sites
The Docs sites field appears when your organization has more than one docs site or the automation already has sites selected. Select sites by their registered URL (host[/basepath]), such as portal.example.com/product-1. Select All docs sites, or leave the selection empty, to include every site in your organization. To change the scope later, open the automation and update Docs sites in Configuration.
Set the schedule
Choose daily or a day of the week, a time of day, and timezone. A schedule fires at most once every 20 hours.
Check what a run produces
Save your new automation.
After creating your automation, select Run now to test the prompt. Manually running an automation doesn’t affect the next scheduled run. Runs take a few minutes, and finished runs are reported via email or Slack when you connect Fern Agent to Slack.
A scoped run can read and edit only the selected sites and open pull requests only in their repositories. The automations list shows each automation’s scope in the Docs sites column.
Everyone in your organization sees every automation, and only its creator can change, delete, or run one. Turning an automation off keeps its prompt and history, while deleting it discards both. Pull requests its runs opened are unaffected.
Run history covers the last 30 days. The Status column shows Running, Successful, or Failed for runs with tracked outcomes. The Pull requests column links every pull request a run opened, labeled owner/name#123, including runs that edit multiple repositories.
Examples
Fix what readers complained about
Review the feedback readers left on our docs pages and fix the pages they said were missing information, wrong, or unclear. Make the changes and open a pull request. Ignore feedback about the product rather than the docs.Report on how the docs are doing
Report on how our docs are doing: the pages readers spend the most time on, where they drop off, the searches that return nothing, and what changed since last week.Fern Clerk
Fern Clerk keeps your docs in sync with your code. Where a scheduled automation runs a prompt at a set time, Fern Clerk runs on code changes: it reviews each pull request in your product repositories, decides whether the docs need updating, and opens a docs pull request when they do.
Set up Fern Clerk
On the Automations page, select Set up Fern Clerk. Setup has four steps.
Connect your code
Select Install on GitHub to install the Fern GitHub App on the repositories whose pull requests should be reviewed, then pick them from the list. You can also enter a repository by name, as owner/name or its GitHub URL. An automation watches up to 20 repositories, all under the same GitHub owner as the repository your docs site publishes from.
Choose how reviews work
Answer three questions:
- When should a pull request be reviewed? See Review trigger.
- What should happen when the docs need to change? See Observe only.
- How should docs changes be grouped? See Grouping.
Ignored paths, folded under the questions, is optional. See Ignored paths.
Pick the docs to keep in sync
Choose the docs site to keep in sync. Docs pull requests open in the repository the site publishes from, so the Fern GitHub App must be installed on that repository too. If your organization has no docs site yet, select Generate docs from your code to have Fern write a first version, or Create a docs site to set one up in a new tab.
Turn on Fern Clerk
Name the automation, then select Authorize to let Fern Clerk act as you. Reviews run with nobody watching, so they use your access and see and change only what you can. One authorization covers all your automations. Select Turn on Fern Clerk, or turn off the toggle and select Create paused to set it up without reviewing anything yet.
Review trigger
With While open, each pull request gets its own draft, so grouping doesn’t apply.
Grouping
When pull requests are reviewed on each merge, grouping controls when the docs changes those reviews call for are written. Reviews themselves always happen as each merge arrives.
A digest suits repositories that merge often. Merges that need a docs change are held, and the digest opens one docs pull request covering them all, adding to the automation’s previous docs pull request if it’s still open. Only the merged pull requests the digest updated docs for get a comment. A digest with no merges waiting does nothing.
While merges are waiting, the automation’s Overview tab shows how many and when the digest runs. Select Open it now to write the digest early. Switching back to With each merge writes the waiting merges without waiting for the next digest.
Observe only
What should happen when the docs need to change? controls whether reviews lead to docs pull requests:
- Open pull requests (default): a docs pull request is opened or added to, and the source pull request gets a comment.
- Observe only: what would change is recorded, and nothing is posted to GitHub. Each review shows up on the automation’s page as the merge arrives. If you later switch to Open pull requests, reviews from observe mode stay marked Observed. Observing first is a safe way to see how your merges are judged before any docs pull requests open.
Ignored paths
Ignored paths lists source paths that never need docs changes, one glob per line:
A merge that touches only ignored paths is marked as needing no docs change, without a review. A merge that also touches other files is reviewed on those files alone. Your globs add to Fern’s built-in skips for tests, lockfiles, CI configuration, generated files, and credential files such as .env and keys. Clearing the field leaves only the built-in skips. A list holds up to 50 globs of up to 200 characters each, and globs that match every file, such as *, **, or **/*, are rejected.
Docs site profile
Each merge is reviewed against a short profile of your docs site: what it documents, who reads it, its main areas, and what it doesn’t cover. Fern writes the profile from your published site, so no docs changes are proposed for products or surfaces your site leaves out. Every automation that points at the same docs site shares one profile.
The profile appears under What Fern Clerk knows about your docs on the automation’s Settings tab. A profile marked Generated from the site shows how many pages Fern read and when, and Fern regenerates it automatically once it’s more than 7 days old. To describe the site in your own words, edit the text (up to 4,000 characters) and select Save profile. The profile is then marked Edited by your team and isn’t regenerated automatically. Regenerate from the site reads the published site again and replaces the profile, including an edited one. If no profile exists yet, the card shows Not written yet and a Generate from the site button.
Generate docs from your code
If you don’t have a docs site, Fern can write a first version from a repository. Select Generate docs from your code during setup or on the automation’s Settings tab, then choose:
- Connect your code: the one repository Fern documents.
- Where the docs go: the same repository, in its
fern/folder, or a separate repository. When the docs live in the same repository, changes underfern/are ignored, so docs pull requests aren’t reviewed as code changes. - Brand (optional): your website, which Fern pulls colors and a logo from so the first version matches your brand.
- Tone & style (optional): guidance on voice, audience, terminology, and dos and don’ts, up to 4,000 characters. Fern follows it when it writes the site and saves it as
fern/AGENTS.mdin the docs repository, so Fern Clerk applies it to later updates too. Edit that file to change it.
Before it starts, Fern checks that your GitHub account can read the repository and write to the docs repository, and asks you to Connect GitHub if it isn’t connected. Fern then reads the repository, plans the site, writes the pages, checks that the docs build, and opens a pull request. The pull request adds up to three workflow files (check, preview, and publish), skipping any the repository already has, and a FERN_TOKEN secret if it doesn’t have one. Merging the pull request publishes the docs, and from then on they stay in sync with your code.
A repository can have one run in progress at a time. Each repository can start 3 runs a day and each organization 10. If a run fails with a retryable error, select Retry on the run.
Automation page
Each Fern Clerk automation has its own page. The header shows the automation’s status, such as Live, Waiting for a merge, No repositories, Generating docs, Needs authorization, or Paused, along with an on/off toggle. The page has three tabs:
- Overview: counts of merges reviewed, merges that needed a docs change, docs pull requests, and failed reviews over a time range you choose, plus the most recent reviews and any merges waiting for a digest.
- Reviews: every pull request reviewed, filterable to Docs updates, No change, or Failed, with each decision and the resulting docs pull request. Mark each decision right or wrong with the thumbs up and thumbs down buttons. Review recent merges reviews your last 10 merged pull requests without posting anything to GitHub, so you can see how your changes are judged without waiting for the next merge.
- Settings: the repositories, the review trigger, mode, grouping and ignored paths, the docs site, the docs site profile, and Delete automation. Deleting removes the review history but leaves the docs pull requests already opened.
Permissions and data
Everyone in the organization sees every Fern Clerk automation. Each one acts as the person who set it up, and only they can change, pause, or delete it, or edit its docs site profile. If their GitHub authorization stops working, the status changes to Reconnect needed and reviews pause until they grant it again.
Fern Clerk redacts secrets from pull request content before reviewing it, skips credential files, and can’t send anything to outside hosts during a review. It scans its docs edits for secrets before committing them.
Privacy and data handling
Fern Agent acts with your own Fern permissions on every surface, so it reads and edits only the sites, analytics, and organization data your account can already see. Requests are scoped to a single session: the prompt, any Slack message or thread you tag it in, and attached files are stored to complete the task and aren’t retained afterward.
Editing is powered by Devin from Cognition. Neither Fern nor Devin uses your data to train AI models: Fern configures its Devin integration to opt out of any data collection for model training, so your messages, code, and documentation content are never used for training.