# How to Turn Your Internal Communications Into Usable Data for AI Agents AI projects often stall because the information the AI needs is spread across too many tools. That is why, for one of our clients, we brought their calls, meeting notes, and Slack messages into a single knowledge base, with the goal of enabling a hiring agent to work alongside their HR team and exploring what else this setup could make possible across the company. - URL: https://sudolabs.com/insights/internal-communications-data-ai-agents - Published: 2026-10-14 - Updated: 2026-10-14 - Author: Martin Sedovic, Head of Growth - Categories: Business, Tech - Topics: Knowledge base for AI agents, AI agents, Data pipelines, AI in hiring, Internal AI automation - Language: English In almost every AI project we work on, the hardest part is getting the model the right information. Sales calls are recorded in one tool, meeting notes sit in another, and most decisions get made in Slack. Each tool stores data in its own format, and none of them talk to each other. An AI agent that can't see this information can only give generic answers. Our client, a US software company, faced exactly this problem. Below, we show in detail how we did it, what a setup like this enables a company to do, and why it is necessary in the first place. --- ## The problem: company knowledge in three separate tools The client wanted AI agents to handle repetitive internal work, starting with hiring. Their knowledge lived in a call-recording tool for sales and customer calls, an AI note-taker for meetings, and Slack. Each tool has its own API (the interface other software uses to read its data), and each returns data differently. The call recorder marks speakers with ID numbers. The note-taker sorts notes into folders. Slack returns messages channel by channel and limits how many you can request per minute. An agent connected to all three directly would have to handle three formats at once, and it would often miss the right passage because similar information looks different in each tool. --- ## What we built: one knowledge base for every conversation We built a pipeline in Python, meaning a program that collects data from each tool and cleans it up. Each tool gets its own connector that downloads the data. A second step converts everything into one shared format: who took part (name, job title, email), when it happened, and the text with each speaker named. After that, a recorded call and a Slack thread look the same, so an agent can search them as one collection. The pipeline runs every day and only downloads what's new since the last run. If Slack rejects a request because too many were sent, or the connection drops, it waits and tries again. During testing the data can sit on a developer's laptop, and once it's live it goes to Amazon S3, Amazon's cloud file storage. Adding another tool later, such as email or a CRM, means writing only one new connector instead of rebuilding the whole pipeline and agent behavior from scratch. --- ## The first agent: hiring Hiring came first because it happens constantly and most of what matters never reaches the hiring software. With calls, notes and Slack in one place, a hiring agent could do the following, while people from HR still make the final decisions: - Draft a job description from what the team said in planning meetings and Slack about the gap they need to fill. - Brief each interviewer on what earlier rounds already covered and what is still unclear, so candidates don't answer the same questions three times. - Compare candidates on the same questions using quotes from recorded interviews, so the panel isn't relying on memory. - Check debrief feedback against the transcript. If someone writes that a candidate couldn't explain a topic, the agent can show the part of the interview where it came up. --- ## What else the same foundation makes possible Until now, nobody at the company, person or tool, could see all of these conversations in one place. The knowledge base changes that: - Tracing a decision made in Slack back to the customer calls that prompted it, or finding customer requests that were discussed internally and never acted on. - Spotting patterns no single employee could notice. If the same complaint comes up in dozens of sales calls and a few engineering threads, nobody sat in on all of them, but an agent that reads them all can flag it. - Keeping knowledge when people leave. With someone's calls, notes and messages in one place, a new hire can ask why something was done and get the answer from the original discussion. --- ## Start with the data, then build the agent Many AI projects start with the agent and run into the data problem halfway through. Sort out the data first, and every agent after the first one is quicker and cheaper to build. If your company's knowledge is spread across calls, notes and chat, [book a call with us](https://calendly.com/martinsedovic/databricks-partnership-with-sudolabs) to plan the data layer and your first internal agent. ## FAQ ### What is a knowledge base for AI agents? It's one place where conversations from different tools, such as call recordings, meeting notes and chat, are stored in the same format, so any agent can use all of it without special handling for each tool. ### Why not connect an AI agent directly to Slack or a call recorder? You can, but each tool returns data differently and limits how fast you can read it. The agent ends up less accurate and harder to maintain. Cleaning the data once gives every future agent the same input. ### Can AI help with hiring without making the decisions? Yes. It can prepare interviewers, compare candidates using interview transcripts and check feedback against what was said, while people make the decisions. ### Is it safe to give an AI agent access to internal conversations? Yes, if you plan access from the start. Decide which channels and calls are included, keep the data in your own cloud account, and have a person approve any decision the agent supports. ### Where should a company start with internal AI automation? Pick one repetitive workflow and check where its information lives. If it's spread across tools, build the knowledge base first. Sudolabs usually starts with a short discovery that maps the data sources and scopes the first agent.