An AI agent can connect to company data, search internal systems, investigate problems, and automate repetitive tasks. But building those capabilities is only half the challenge. The harder question is whether people across the organization can understand the tool, trust it, and use it to solve problems they already face.

Consider how much time a team can lose simply trying to find information. A support specialist receives a customer complaint and needs production logs to understand what happened. A product manager wants to examine a user journey but depends on someone else to retrieve the analytics. An engineer investigates an issue by moving between tickets, dashboards, and internal discussions before finding the missing piece of context. None of these tasks necessarily requires hours of complex technical work, yet each can involve several people, multiple systems, and repeated explanations.

An internal AI agent can reduce that friction by bringing information together and helping employees investigate questions independently. But success does not come from connecting the largest number of tools or choosing the newest AI framework. It comes from making useful company knowledge accessible while maintaining clear security boundaries, learning from real usage, and fitting into the way people already work.

One company's experience building an internal agent offers an important lesson for any team introducing AI: the technology becomes valuable when it solves recognizable problems for real people, not simply when it demonstrates impressive capabilities.

That company's internal agent began with a relatively narrow engineering use case in January 2026. Structured backend events were already stored in ClickHouse, and engineers could investigate production questions by writing SQL queries. The initial experiment was straightforward: could an AI agent investigate the same data?

Once that worked, the system expanded to connect with tools such as Slack, Linear, PostHog, and Grafana. Each connection made it possible to gather context from another part of the company rather than treating every question as an isolated task.

This is a practical way to approach internal AI development. Instead of beginning with a broad ambition to transform every department, identify one recurring task that consumes time because information is scattered, access is inconvenient, or the investigation requires help from another team.

For example, when a support specialist receives a report about a product problem, the immediate need is not necessarily to generate a sophisticated AI response. The real need is to understand what happened. That may require examining backend events, finding a related issue in Linear, and checking relevant dashboards. If an agent can retrieve and connect that information, the support specialist may be able to investigate the problem without waiting for an engineer to assemble the evidence.

The reported impact was substantial for the workflows being targeted. Investigations that previously took multiple hours and required access or context from three or four people could often be completed in zero to one hour. The system also helped with parts of dashboard setup and analysis in PostHog and Grafana.

Those results illustrate the difference between a useful internal tool and an impressive demonstration. The value is not that the agent can interact with several systems. It is that employees can complete meaningful work with fewer delays and less dependence on other people.

Tip: Choose one frequent, time-consuming workflow and measure how long it takes before and after introducing AI. Start with a problem employees already recognize instead of asking them to invent reasons to use a new tool.

One of the most effective adoption decisions was making the agent visible in shared Slack channels and Linear rather than keeping it hidden behind a separate application.

That choice matters because people do not automatically understand what a new tool can do. A blank chat window offers very little guidance. Even a list of suggested prompts requires employees to imagine how those examples might apply to their own responsibilities.

A shared interaction makes the possibilities concrete. Someone asks the agent to investigate a production issue, and colleagues can observe the question, the investigation, and the resulting explanation. A product manager may recognize a way to analyze user behavior. A support specialist may discover that a recurring customer report can be investigated without waiting for engineering. Another employee may notice that the agent can collect information they currently gather manually.

Every successful interaction becomes a practical example that other people can adapt.

There is also less friction when the tool appears inside an existing workflow. If employees already use Slack to discuss issues and Linear to manage work, they do not need to remember another destination or change their habits before receiving value. They can encounter the capability in the same place where the question arises.

A dedicated web interface still has a purpose, particularly for private investigations or longer tasks. The important point is that a single interface does not have to serve every situation. Shared channels can make capabilities visible, while other interfaces support work that requires more privacy or concentration.

This is especially relevant when introducing AI to a company with different levels of experience. Experienced users may quickly discover advanced applications, but others need examples that connect directly to familiar responsibilities.

Tip: Introduce AI through the tools employees already use, and share real examples of completed work. Demonstrate how the agent solves a specific problem instead of relying on feature announcements or general explanations of its capabilities.

An AI agent becomes more useful when it can work with information from multiple systems. A production event may explain when something happened, a Linear ticket may show whether the issue is already known, and a dashboard may reveal whether the problem affected a wider group of users.

Individually, these sources provide pieces of the answer. Together, they can help an employee understand the situation much faster.

In this case, the agent's integrations expanded beyond ClickHouse to include systems such as Slack, Linear, PostHog, and Grafana. When useful information is distributed across these tools, the agent can reduce the need for employees to search each one independently and manually assemble the context.

However, more integrations do not automatically mean a better system. Every connection introduces questions about authentication, permissions, reliability, and the quality of the information returned. An agent that can access everything without meaningful boundaries may create more risk than value.

The implementation used small command-line tools, including wrappers around OpenAPI endpoints and existing software development kits, to expose the specific operations needed. These tools returned structured results, handled errors, and kept credentials away from the model. The goal was not to build a universal integration platform immediately, but to provide controlled access to the systems relevant to the work.

The security boundary was deliberately simple: access was gated through Google sign-in for the company's domain, and remote system access was read-only. This prevented the agent from directly modifying remote company systems through those integrations, rather than relying solely on the model to decide whether a change was safe.

Read-only access does not eliminate every security risk. Sensitive information can still be exposed to an unauthorized user if access controls are poorly designed, and returned information can still be misinterpreted. Identity, permissions, data handling, and auditing therefore remain important.

The broader lesson is to make the safe path the default. A model can help interpret information, but critical security boundaries should be enforced by the systems surrounding it.

Tip: Connect only the systems required for the first workflows, keep credentials outside the model's reach, and enforce permissions at the tool or service level. Begin with read-only access when investigation and analysis are the primary goals.

As an internal agent becomes part of daily work, usage data can help explain whether it is genuinely useful. In this case, analytics were introduced early to track tool calls, token spending, recurring workflows, and broader usage patterns.

The system consumed billions of tokens per month, making cost awareness an operational concern rather than a theoretical consideration. At that scale, understanding how the agent is used can help identify expensive workflows, repeated requests, and opportunities to simplify how tasks are completed.

But the purpose of measurement matters just as much as the measurements themselves.

A usage dashboard can become a leaderboard that ranks employees by how frequently they use AI. That may look like a convenient way to demonstrate adoption, but it can encourage people to use the tool even when it is unnecessary. It also says little about whether the work improved.

A better approach is to examine patterns that can guide product decisions. Which capabilities are used repeatedly? Which tools consume substantial resources without delivering clear value? Are people trying to perform tasks the system cannot handle? Are useful features going unnoticed because employees do not understand how to access them?

These questions connect analytics to improvement. If employees repeatedly struggle with a particular workflow, the solution might be better instructions or a simpler interface. If a connector is rarely used, it may be poorly described, difficult to discover, or irrelevant to actual needs. If a workflow requires excessive model calls, it may need a more efficient design.

Usage data should also be interpreted carefully. Frequent use does not automatically mean high value, and infrequent use does not always mean a feature is unnecessary. Some capabilities are needed only during unusual incidents, making their value difficult to judge by frequency alone.

The strongest measurements combine operational information with feedback about outcomes. Time saved, fewer handoffs, faster investigations, and improved access to information can provide a clearer picture than raw interaction counts.

Tip: Track the cost, reliability, and outcomes of important workflows rather than ranking employees by AI usage. Use aggregate patterns to improve the tool, and investigate whether frequent activity translates into better work.

Internal tools rarely behave exactly as their builders expect once employees begin using them. People ask unexpected questions, discover confusing interactions, and attempt tasks that were not part of the original design.

These moments are not merely defects to fix. They are evidence about how the tool fits into real work.

In this case, employees could provide feedback as they used the agent, and improvements followed those experiences. This created a short feedback loop: someone tried a workflow, encountered a problem, explained what went wrong, and could often test an improved version soon afterward.

That responsiveness can encourage experimentation. Employees are more likely to explore a new capability when a failed attempt leads to improvement rather than leaving them with the impression that the tool is unreliable or difficult to use.

Documentation supports the same process, but it does not need to become a lengthy manual. A useful starting guide can explain what the agent can access, provide examples of effective requests, identify known limitations, and show how to report problems.

The relationship between documentation and feedback is important. Documentation helps people get started without repeatedly asking the same questions. Feedback reveals where those instructions are incomplete or where the product itself needs to change.

Neither is sufficient on its own. A detailed guide cannot anticipate every situation, while an informal feedback channel can become overwhelmed if common problems are never documented or fixed.

There is also a trust consideration. Employees need to know what happens when they report a problem and whether their feedback can influence the tool's development. When improvements are visible, people can see that their experience matters.

Tip: Provide one obvious way to report problems and suggestions, then close the loop by communicating what changed. Turn recurring questions into documentation and recurring frustrations into product improvements.

Because the original use case involved production data and observability, an engineering-focused agent would have been a natural endpoint. Instead, the system became useful across product, support, operations, marketing, and growth.

That expansion highlights a common opportunity in internal AI: different departments may struggle with the same underlying problem even when their responsibilities look very different. They need information spread across several systems, but they may not have the technical skills, access, or time to collect it efficiently.

Support teams, for example, can benefit from the ability to investigate many customer reports independently. Product teams may need to understand user behavior across analytics tools. Operations teams may need to collect information from several internal sources before making a decision. Marketing and growth teams may need to analyze performance without waiting for someone else to retrieve the data.

A shared agent can reduce these barriers when it provides relevant context and respects each user's permissions.

Interestingly, technical teams may not always be the easiest group to persuade. Engineers may already use coding agents, terminal-based workflows, custom instructions, and personal configurations that they have refined over time. A new company interface may feel like a step backward if it forces them to abandon useful context or preferred tools.

Other departments may have fewer existing AI workflows to replace, so a practical example can reveal immediate value.

This is why company-wide adoption should not mean forcing everyone into the same interface or workflow. Different roles need different entry points, capabilities, and levels of explanation. A common foundation can support the organization without requiring identical habits from every employee.

The goal is not to make every department use AI in the same way. It is to give each department a safe and useful way to apply it to its own problems.

Tip: Identify one high-friction workflow in each department and demonstrate a relevant use case. Preserve useful existing workflows where possible, and adapt the entry point to the people who will use the tool.

A tool that spreads across a company creates a new challenge: its continued improvement should not depend entirely on the person who originally built it.

Employees may discover useful workflows, identify missing integrations, or develop instructions that help others complete recurring tasks. But they will not necessarily know how to contribute those improvements safely.

An agent can combine code, prompts, connectors, credentials, and permissions. Even an apparently small change may have consequences if it exposes sensitive information or breaks a workflow used by multiple teams. Employees may therefore hesitate to contribute, particularly when the process is unfamiliar or ownership is unclear.

Contribution paths, however, remained an unresolved challenge. The repository was available, but it was not obvious how someone could safely write a skill, add a connector, or modify instructions. As a result, too much of the improvement process still depended on a small number of people.

Making contribution easier does not mean allowing everyone to change production behavior without review. It means creating a clear path from idea to tested improvement.

A contribution guide can explain how to propose a change, where to find examples, how to test it safely, who reviews it, and which modifications require additional security checks. Smaller contributions, such as improving instructions or documenting a workflow, can have a simpler path than changes to authentication or data access.

Ownership matters too. When people know who maintains a connector or approves a particular type of change, they are less likely to avoid contributing because they fear breaking something important.

The objective is to distribute useful knowledge and ideas without distributing uncontrolled access.

Tip: Create a contribution guide with examples, named owners, testing instructions, and review requirements. Make low-risk improvements easy to propose while applying stricter controls to changes involving permissions, credentials, or sensitive data.

AI engineering tools and conventions change quickly. New frameworks appear, models improve, and approaches to connectors, memory, evaluation, and orchestration continue to evolve. Keeping up with these developments can be useful, but it can also become a distraction.

A team may spend weeks debating whether to adopt a new architecture while the existing system still has obvious problems to solve. A promising framework may become popular before the team has enough evidence that it will improve its own workflows. Repeated redesigns can also create maintenance work without delivering a meaningful benefit to users.

For internal tools, simplicity is especially valuable. The system does not need to become a universal platform that supports every possible agent use case. It needs to solve the company's actual problems reliably and remain understandable enough to maintain.

That usually favors a straightforward architecture, narrowly scoped connectors, clear boundaries between components, and limited dependence on a single model or framework where practical. Components can be replaced when real requirements justify the change, rather than whenever a new approach attracts attention.

The same principle applies to evaluation and tracing. Some observability is necessary to diagnose failures, monitor costs, and verify that permissions are respected. Critical workflows should have representative tests. But building elaborate evaluation infrastructure before the product has demonstrated a need for it can divert time from improvements that users would notice immediately.

The appropriate level of engineering depends on the risk and importance of the workflow. An agent that provides information for a low-risk internal question may not need the same evaluation system as one that supports consequential operational decisions. More rigorous controls become justified when failures are recurring, the impact is serious, or the system's behavior is difficult to predict.

The objective is not to minimize engineering discipline. It is to apply that discipline where it protects reliability, security, and user outcomes.

Tip: Choose the simplest architecture that meets current requirements, test critical workflows and permissions, and expand evaluation or tracing when actual failures and risks justify the additional complexity.

One of the easiest mistakes to make when building an internal agent is confusing the builder's understanding with the user's understanding.

If you work with AI every day, concepts such as connectors, context, skills, memory, and tool calls may feel ordinary. For someone who has only used a basic chatbot, those concepts may be unfamiliar. Even employees who understand AI in general may not know what a particular company agent can access or how its capabilities differ from a public chatbot.

A system that seems obvious to its creator may therefore appear to other employees as nothing more than another chat window.

They may wonder why they should use it instead of ChatGPT, what company information it can access, whether it can change something without permission, or which questions it can answer reliably. If those questions remain unresolved, employees may avoid the tool even when it could save them time.

The answer is not necessarily more technical documentation. It is to make the benefits concrete.

Show employees how the agent can investigate a familiar issue, assemble information for a recurring report, or answer a question that normally requires several manual steps. Explain what information it can access, what it cannot do, and where human verification remains necessary.

Examples should also reflect the needs of different roles. An engineer may care about production diagnostics, while a support specialist may care about investigating a customer report. A generic demonstration can miss both audiences if it focuses on technical sophistication instead of practical value.

AI literacy develops through use, but the first experience matters. When people understand what the system can do, where its limits are, and how it helps them, they have a clearer basis for deciding when to rely on it.

Tip: Explain AI capabilities through familiar tasks, not technical terminology. Demonstrate one relevant workflow, state its limitations clearly, and show users how to verify important results.

A successful internal agent is not defined by how many integrations it has, how sophisticated its architecture looks, or how much activity appears in its usage dashboard. Those details matter only insofar as they help the system deliver value safely and consistently.

The more useful questions are practical. Can employees find the information they need without unnecessary handoffs? Can they investigate common problems faster? Are permissions clear and appropriately restricted? Do people know how to use the tool, report failures, and contribute improvements? Can the system be maintained without requiring a small group of specialists to handle every change?

This company's experience shows how a narrow experiment can expand into a shared company capability when it connects useful data, fits existing workflows, and improves through actual use. It also shows that adoption, contribution, education, and maintenance require deliberate attention. These challenges do not disappear simply because the underlying model becomes more capable.

If your team is considering an internal agent, start with a real problem, connect only the systems needed to solve it, establish clear access boundaries, and make the result visible to the people who can benefit. Measure outcomes rather than activity alone, and let feedback shape what comes next.

Most importantly, remember that building the agent is not the same as building a useful product. The technology provides the capabilities, but the surrounding system determines whether people can trust them, understand them, and turn them into better work.

Hit reply and tell me: what is one internal AI tool your company launched, and what made people actually use it or ignore it? I read every answer.

One more from today's sponsor, which helps keep Tiny Big Spark free:

Keep going, one small spark at a time.

Erwin