# Onboarding to Unblocked, with Unblocked URL: https://getunblocked.com/blog/onboarding-with-unblocked/ Published: 2026-10-20T18:30:00.000Z Author: Birgitta Boeckeler Categories: Context Engine, Product What changes when a new engineer can tap into a company’s code, conversations, documentation, and decision history through a context engine from day one? I used Unblocked to onboard to Unblocked and find out. --- I was a consultant for over 20 years, so I like to think that I'm a bit of an onboarding expert - I've had to very quickly onboard into many engineering organizations. That usually involved getting a high level mental model of the code and architecture, understanding the domain, mapping out who I can ask about what, and most importantly: What were we doing and why were we doing it? To use a phrase my new team at Unblocked likes to use: [I was the context engine](https://getunblocked.com/blog/you-are-the-context-engine/), or rather, at every new client I had to become one, sometimes just based on hallway conversations and limited wiki access. Joining Unblocked gave me my first opportunity to onboard into an organization where all of the digitized organizational knowledge was already wired up for AI. Most of my access to this knowledge came through the Unblocked product itself. Overall, it was amazing to have all this knowledge available without having to constantly interrupt my new team mates. And looking back on my first task, there are multiple dead ends I didn't walk into, and rework I avoided. The context I had while preparing my first feature implementation let me contribute almost autonomously from the start. And I could see first hand how valuable it is when that context is not just about the status quo, but can help me understand the "why" and "who" as well. Overall, LLM-backed systems helped me with all kinds of newcomer questions, from go-to-market, to customer FAQs and case studies, to current KPIs. But I will focus here on what Unblocked is meant for and best at: How it helped me build software. ### My first task The team asked me to make a seemingly simple change to the Unblocked MCP server. The server sits in front of all the systems the team has connected, in our team’s case the main sources are GitHub, Slack, Linear, and Notion. But the tool description in the MCP server was still static and didn't yet tell the agent which of those sources _this particular_ organization actually has, so an agent had no way of telling whether a question about a Linear ticket was even worth a tool call. My job was to make that description list the organization's real integrations. Even though it was a small change, it turned out to be a good showcase for how Unblocked helped me onboard, because there was a lot of tricky context to consider. ### Preparation First I needed to break down what _exactly_ the requirements were. The high-level ask was "the tool description should dynamically list all the external integrations and connected MCP servers behind the MCP server". I used a skill in Claude Code that keeps looking for and asking open questions about the requirements, and Claude Code had access to Unblocked while it was doing that. **Domain language and data model** Some of the more basic domain language explanations I needed were derivable by Claude Code directly from the code (e.g. the difference between "installation", "provider" and "data source"). However, relying only on the code was not enough when I was trying to understand the MCP terminology and setup: Unblocked is an MCP server itself, but it can also act as an MCP client when customers add their own or 3rd party MCP servers to it. To help me disentangle this, Unblocked showed me historical information from Slack and Linear. Another data model question came up right at the beginning of the Q&A: which data field to use when listing the sources. The agent can of course derive from the code which fields are available, and could have shown me those options on its own. But Unblocked added information about a previously abandoned PR that had already wrestled with this exact question, plus a Slack thread where the team had debated the available fields in a different context. It also flagged the risk of prompt injection, and how the team had dealt with that before. This was one of the examples that made me feel the most like I was using a context engine, not just individual MCP servers, as Unblocked could cross-reference and surface all of those sources of information in one go. **Product and customer context** MCP tool descriptions are a sensitive surface area for a product like ours. Unblocked pulled up Slack conversations about previous difficulties and customer feedback on how frequently the MCP server gets called. This helped me better understand the potential impact of my changes, and what I needed to be careful about. **Previous research** In the past, the team had documented their experience that many MCP clients basically ignore the server description, and that the tool descriptions are what actually matter. They had also found that Claude Code truncated tool descriptions at 2,048 characters at the time, and that some other harnesses cut them off even earlier. Unblocked pulled this out of a Notion document and a Slack thread during the grilling, reminding me of the importance of tool description length - though I did have to double check this information against the current state of tools of course. **Previously started work** Apparently this feature had been started in the past, but never merged. Unblocked found the old PR with the beginning of the implementation and some of the comments made at the time. As part of that work, some of the concerns about respecting access controls had already been thought through, which was a good starting point for the new implementation. **Where to change the code** Claude Code by itself could help me find the right place to implement this just fine: an existing "macro" feature that allows the resolution of predefined placeholders in the tool descriptions. However, I had some questions about why it was implemented the way it was, to decide whether any refactoring was needed. Unblocked could give me that history based on PR review comments and Slack threads from February. **Real data to tweak the solution** I had to be mindful of the length of this dynamic list, to not overly bloat the tool description. So I needed to get an idea of what this list of data sources would typically look like. Our internal version of Unblocked has access to some production insights, so I could ask it to get me the longest and a few average examples of real integration configurations. The LLM then took that data and helped me think through the character budget, and gave me examples of what the resulting text would look like. This real data also turned up new insights for me about the data model and the edge cases. ### Time to check my work At this point, I had a list of assumptions and open questions, and I took those to - a human! Unblocked has the ability to determine who is an expert in which parts of the codebase, based on recent PR history and change volume. I didn't use that feature in this case, but it would have been amazing to have in all those onboardings in the past, where I had to ask my way through a chain of people until I found the person who could answer my question... The questions I'd gathered with Unblocked's help were all valid, and had helped me prepare a much more effective conversation than I could have had without it, _especially_ as a new team member. The main correction was about a set of flags in the data model that my planning had assumed were relevant, but they weren't. Some of the open decisions could be resolved in this conversation, others we were still unsure about - I had to start the actual implementation to get more insights and data. ### Implementation Analysis of my coding agent transcripts shows that during the actual implementation, when Unblocked was called, it mostly returned code results, other team context wasn't as needed anymore. The organizational context - the Slack threads, the old PRs, the Notion page - had already done its work during planning. This type of context pays off especially where decisions need to get made. By the time I was implementing, the questions that needed history to answer had been answered. Unblocked became relevant again during code review, though it turns out that for my particular changes, the code review didn’t reach out for context other than the code itself. One caveat on this: I was working in a monorepo, so the agent already had all the code on my machine. In setups with multiple repositories, Unblocked would have provided code context from other repositories in the organization. While my coding agent didn’t use Unblocked as much anymore during implementation, I myself used it to ask all kinds of one-off questions to continue my onboarding, e.g. to clarify terminology, discover team conventions, or to help with environment setup. **Local environment setup** Coding agents shorten the grind of running services and tests locally for the first time. This is heightened when they can see the team's historical context, because these are exactly the kinds of problems that get solved once in a Slack channel and never written down anywhere else. I would say though that environment setup, while a lot faster, will probably always remain a somewhat annoying process, especially for more complex parts. For example, how do I point the MCP server in my local harness at different environments, let alone localhost, including authentication?! This was one of the examples where I had to ask for human help. On a side note: I also got to learn from conversations that multiple members of the team have local setups that diverge from the “official” documentation that Unblocked kept showing me - the signs of a world in which it is super easy to generate your own little utilities. **Testing approach** Finally, Unblocked made me aware that there is an admin-only override for the tool descriptions, which was a very useful way to test the macro for a specific organization first - deploy but not release it yet. Without this information, I might have wasted a bunch of time figuring out how the feature toggles work. **Where are the limits?** It wasn't all perfect of course. At one point, Unblocked treated an intermediate state of a historical PR as the current implementation. It also surfaced some noise that wasn't relevant, and failed to flag early enough that one type of integration needed to be expanded further in the list - a gap in my domain knowledge that ideally should have gotten filled in. It's also worth noting that whatever a context engine surfaces still has to be interpreted by its consumer: in one case, Codex over interpreted a piece of context it got from Unblocked and went on a bit of a wild goose chase. And I myself noticed only during my retrospective analysis for this post that I had missed an important piece of information at the beginning - it was there, I just didn't read it right. Beyond this coding task, regarding my overall onboarding to the systems architecture, beyond this task: I feel like I got a solid high level picture slightly faster than in the past, but there is still nothing like spending an hour in front of a whiteboard with a human. ### The social side of onboarding I'm conscious that as I walked through this journey, I implicitly presented human interactions as something inefficient, almost like a bad thing. After all, it's common practice to assume that onboarding a newcomer temporarily reduces the capacity of valuable existing team members. And on the onboardee's side, there is an aspect of vulnerability: you're new to the team, it's still hard to gauge the level of "stupidity" a question might reveal, so asking a machine the same question feels much safer. I actually got the advice to ask more of my questions in a team Slack channel instead of privately - somebody might correct the answer if it's wrong, which is worth a lot when you're still too new to tell that yourself. Plus, the corrections land in Slack, which is one of the places Unblocked reads from, so the next person who asks gets the corrected version. However, the gained speed comes at a price as well - direct human interaction and getting to know each other is an important aspect of onboarding that goes way beyond sharing knowledge and information. My new team works mostly face to face in an office, which makes it a bit easier to offset the decrease in human contact during onboarding. I meet them at the coffee machine, the communal lunch table, and I can chat from one table to the next. But with all of these machines available to answer my questions and provide context, I have definitely felt that I have to more consciously push myself to do that. And I can only imagine how hard it would be to get to know the team if I was working remotely. ### In summary I got to a working mental model, and a working feature, faster than I think I could have before when I was new in an organization, without leaning too much on anyone's time. Much of that speed came from detours I never took, like the time I didn't spend using the wrong field, or the time I saved by not overcomplicating how to test. On the flip side, in this new onboarding experience I now have to be more deliberate about reaching out to people to not miss out on tacit knowledge and nuance, and to build the relationships that are important for building something together as a team.