In most teams, only developers can answer questions about how the system actually works.
Everyone else depends on them. Not because the information doesn't exist, but because it's not accessible in a practical way. It lives in the codebase, scattered documentation, tickets, and in people's heads.
So even basic questions become dependent on someone else's time. How does authentication work here? What's the token lifetime? Why is this failing? These are not complex questions, but answering them usually means digging through the code or asking someone who already knows.
That dependency slows things down more than it should.
Dawn
Dawn is a simple idea. Developers have Cursor, Codex and Claude. Everybody else has Dawn.
It connects to your system — codebase, architecture, tickets, documentation — and lets anyone on the team ask questions about it. You ask from Slack, Teams, Telegram, Discord, or web chat, and you get an answer based on your actual system. No separate interface, no special workflow.
What This Actually Enables
In practice, Dawn handles the kinds of questions that come up every day but are rarely documented in one place.
You can ask how something works, and get an answer that reflects the actual implementation rather than a general explanation. That includes things like authentication flows, validation rules, background processes, or how different services interact.
You can ask where something is implemented, and Dawn will point you to the relevant parts of the system — a file in the codebase, a service, a configuration, or a related ticket or document.
You can ask why something behaves in a certain way, and get context based on how the system is currently wired together. This is often the difference between guessing and understanding.
Because Dawn is connected to your repositories, issue trackers, and internal documentation, its answers are grounded in the same sources your team would use manually. The difference is that you don't have to navigate those sources yourself. And this works across the tools your team already uses — a question asked in Slack or Teams is answered in that same context, without switching environments or setting anything up separately.
If you ask "How do we handle auth token rotation in the payments service?", Dawn explains the approach used in your system, references the relevant implementation, and points to the actual files. If you ask "How does authentication work?", you get a concise explanation of how it is implemented in your system. If something isn't behaving as expected and you ask "Why is this failing?", you get context that reflects the current state of the system, not a generic answer.
Who This Is Useful For
Dawn is primarily for people who need to understand the system but don't work directly in the codebase. QA engineers can understand behaviour without tracing it manually. Business analysts can verify how things are implemented. Product managers can see how the system actually works, not just how it was designed.
It also reduces the number of interruptions engineers deal with for these kinds of questions.
Six Channels, One Agent
Most AI tools live in their own interface. Dawn works where your team already communicates.
A single Dawn agent can be deployed across all six supported channels simultaneously. The same agent that answers architecture questions in your Slack #engineering channel can respond to support queries in a web widget on your documentation site and handle automated reports in a Teams workspace.
Slack is the most common starting point. Dawn integrates through the Slack Events API, responding to mentions and direct messages. You can configure whether the agent responds to every message in a channel, only when mentioned, or only in direct messages. The agent maintains thread context, so follow-up questions in the same thread build on what was already discussed.
Microsoft Teams works similarly through the Bot Framework. Discord and Telegram each have their own integration path, but the experience is consistent — the agent receives messages, searches connected sources, and responds in context.
The web widget is useful for embedding Dawn on internal tools, documentation sites, or support portals. It generates a small code snippet you drop into any page, and it connects back to your Dawn workspace. Image uploads, file attachments, and conversation history all work through the widget.
For systems that don't fit neatly into a chat interface, the webhook channel accepts HTTP requests and returns agent responses programmatically. This is how teams integrate Dawn into CI pipelines, monitoring alerts, or custom internal tools.
The key point is that you configure the agent once — its model, its connected sources, its skills and memory — and it works the same way regardless of which channel the question comes through.
Connected to Your Actual Systems
Dawn's answers are only as good as the context it has access to. That's why integrations are central to how it works.
Dawn connects to external systems across different categories: source control, project management, and documents.
For source control, Dawn supports GitHub, Azure DevOps, Bitbucket Cloud, and GitLab. Once connected, the agent can search across repositories, browse file trees, read specific files, look at pull requests, and reference issues. When someone asks about a piece of the system, the agent doesn't guess — it finds the relevant code and explains what it sees.
For project management, Dawn connects to Jira, Linear, and Trello. The agent can look up tickets by ID or search across projects, check sprint status, and understand what work is in progress, blocked, or recently completed. This is particularly useful for questions like "what's the status of the auth migration?" or "are there any open bugs related to the payments service?"
For documents, Dawn connects to Google Drive and OneDrive. Teams that maintain architecture decision records, runbooks, onboarding guides, or design specs in shared drives can make all of that accessible to the agent without moving it to a different system.
Dawn doesn't index everything upfront. It searches connected sources in real time when it needs to answer a question.
Memory That Compounds
Most AI conversations are disposable. You ask a question, get an answer, and the context evaporates. The next person who asks a similar question starts from zero.
Dawn agents maintain memory — persistent, evolving and structured documents that the agent reads and writes across conversations. Memory pages are not conversation logs. They are living reference documents that the agent actively maintains.
A memory page might start as a brief note about how your team handles database migrations. Over multiple conversations where migration patterns come up, the agent refines and expands it into a comprehensive reference. The next person who asks about migrations gets the benefit of all the previous context without anyone having to manually write documentation.
Memory pages have access controls. You can make a page available to all agents in the workspace, restrict it to agents with specific tags, or keep it private. This is useful when different agents serve different teams or functions and shouldn't share context.
Thread continuity works alongside memory. When someone returns to a conversation thread days later and asks a follow-up question, the agent picks up where the thread left off. It doesn't lose the earlier context just because time has passed.
Scheduled Tasks
Dawn agents can do work without anyone asking. Scheduled tasks run on cron expressions — the same scheduling syntax used in CI pipelines and system administration — and execute agent prompts on a recurring or one-time basis.
A daily standup summary that pulls open PRs from GitHub and in-progress tickets from Jira, formatted and posted to #engineering at 9 AM. A weekly dependency audit that checks for outdated packages and posts findings to a designated channel. A periodic documentation drift check that compares what the codebase does with what the docs say it does.
These tasks run in the background. Results are delivered to a target channel or conversation. You can pause, resume, or delete tasks at any time.
This turns the agent from something reactive — it answers when asked — into something proactive. Routine information gathering, reporting, and monitoring happen automatically, freeing the team to focus on work that requires judgment.
Skills and Model Selection
Not every agent should behave the same way. Dawn provides two mechanisms for shaping agent behaviour: skills and per-agent model selection.
Skills are reusable instruction packages written in markdown. They define how an agent should approach specific domains — code review guidelines, incident response procedures, onboarding checklists, compliance checks. Skills can be assigned to specific agents and scoped to specific channels. A code review skill might only activate when the agent is responding in a pull request channel, while a general support skill applies everywhere.
Each agent can also use a different AI model provider. Dawn supports Anthropic, OpenAI, Google, and Azure OpenAI. Within each provider, you can select specific models and configure parameters like temperature and maximum token length. A customer-facing support agent might use a model optimized for clear, concise explanations, while an internal engineering agent might use one with stronger code reasoning capabilities.
This means you can deploy multiple agents in the same workspace, each tailored to a specific function, audience, or domain — without one-size-fits-all compromises.
Workspace Isolation and Governance
Dawn workspaces are complete boundaries. Agents, channels, integrations, credentials, conversations, memory, and skills all belong to a single workspace and never cross into another.
This is architectural isolation, not just permissions. A workspace's data is stored and processed separately. There is no mechanism for one workspace to access another's resources, even for administrators. This matters for organizations that manage multiple projects, clients, or teams with different access requirements.
Access is governed by role-based controls, and all agent actions — tool calls, source lookups, memory updates, message responses — are recorded in an audit trail for full operational visibility.
What Changes
The main change is that access to information is no longer tied to specific people.
Questions don't need to be routed through engineers. Answers don't depend on who is available. Teams don't have to rely on incomplete or outdated documentation.
Dawn doesn't replace documentation or engineering. It makes existing knowledge easier to access — for everyone on the team, in the tools they already use, with context that reflects the actual state of the system.
Getting Started
Setting up Dawn takes about ten minutes.
Sign in and create a workspace. Create your first agent and adjust its initial settings — or leave the reasonable defaults. Connect a channel — Slack is the fastest to start with, Telegram and Teams are easy to set up too. Link at least one integration — a GitHub repository, a Jira project, a Linear workspace — so the agent has real knowledge to work with.
From there, your team can start asking questions. As you add more integrations, configure scheduled tasks, and build up memory pages, the agent becomes increasingly useful. Not because the model gets smarter, but because the context it operates with gets richer.
Dawn is live at app.dawnhq.ai. Full documentation, including setup guides for each channel type and integration, is at dawnhq.ai/docs.
