Expanding Agent Knowledge to a New Team Without Rebuilding
Evaluate how an agent knowledge platform can serve another department: extend vocabulary, test access boundaries, assess reindexing needs, and plan migration.
Key takeaways
- Inventory reusable platform components and new team-specific work before connecting sources.
- Map the new team’s terms to shared concepts, while preserving meanings that are genuinely team-specific.
- Test access denial through the complete answer path, including snippets, citations, relations, and caches; also test revocation.
- Pilot both new-team questions and held-out existing-team questions, tracking quality, failures, freshness, and human review effort against agreed limits.
- Reprocess the affected scope when parser, chunking, embedding, or schema changes alter stored representations or retrieval; do not assume every rollout needs a full rebuild—or that none do.
Adding a team should be treated as a controlled rollout, not as a promise that an existing knowledge system will work unchanged. Start by separating what can be reused—storage, identity, connectors, retrieval settings, monitoring, and operating procedures—from what must be added or revalidated for the new team: data access, terminology, mappings, permissions, indexing behavior, and accountable owners. Reprocess only the affected content when a change requires it, and keep the existing team’s access and answer quality in the pilot.
A phased rollout for a new team
Phase 1: Inventory the reusable foundation
Name the components that the existing team uses and mark each as reuse, configure, extend, or replace for the new team. Include source connectors and credentials, document formats and parsers, chunking and embedding settings, schemas and metadata, retrieval filters, permission enforcement, agent tools, monitoring, refresh schedules, and incident procedures. Confirm which components are platform capabilities and which depend on customer-built integrations or operating work.
Then inventory the new team’s sources and workflows: who owns each source, how often it changes, which records are sensitive, whether its content is already indexed elsewhere, and how the team expects answers to be used. Record a baseline for the existing team before changing shared components.
Phase 2: Map vocabulary and data boundaries
Ask subject-matter owners to supply real questions, terms, acronyms, aliases, and examples of concepts that look alike but mean different things. Create explicit mappings for shared concepts, team-specific terms, and unresolved collisions. For example, “account” could mean a customer relationship in one team and a ledger record in another; keep the distinction visible in metadata, retrieval scope, or answer guidance instead of flattening the terms into one label.
For each source and content class, define who may discover, retrieve, quote, follow a relation to, or administer it. Decide which attributes are authoritative, who maintains them, and what happens when an attribute is absent, stale, or contradictory. NIST’s ABAC guidance describes authorization decisions based on subject, object, operation, and, where applicable, environment attributes evaluated against policy. Reusing an existing rule is conditional on trusted attributes being available and the policy actually applying to the new department; it does not guarantee that the policy remains appropriate or unchanged. NIST’s general ABAC guidance is not evidence that a particular product, including AKB, ships ABAC.
Phase 3: Connect, index, and assign ownership
Add the source and connector deliberately. Validate authentication, least-privilege access, parsing, metadata, refresh behavior, deletion handling, and error reporting before exposing results to users. Assign one accountable owner for each operational responsibility: source accuracy, connector health, vocabulary decisions, access policy, retrieval evaluation, and rollout approval. A connector being technically available does not make the source maintained or the workflow supported.
Choose a small, representative content slice for the first index. Compare parsed text and metadata with the source, then test retrieval and access rules before broadening scope. Maintain a change log that ties configuration changes to the affected data and the validation results.
Phase 4: Run a two-team pilot
Build a fixed evaluation set with new-team queries and held-out existing-team queries that were not used to tune mappings or prompts. Include straightforward lookups, multi-document questions, ambiguous terminology, recently changed content, and questions that should have no supported answer. Record expected evidence and who will judge each answer. Keep test data and permission identities representative of real usage.
Test both allowed and denied access end to end. For denied cases, check not only the final answer but also retrieved snippets, citations, relation traversal, search results, logs visible to users, and cached responses. Remove or change a user’s permission and verify that access is revoked across the same paths. Include cases where one team’s term collides with another team’s terminology, and test whether answers stay in the correct source and team scope. A finite pilot with zero observed leaks does not prove the absence of vulnerabilities; continue monitoring and retest access paths after changes.
Track results rather than relying on a single quality score. At minimum, report correct and supported answers, unsupported or failed answers, access-control failures, freshness against source updates, and human review hours. Break results down by team, query type, and source. Agree on acceptable limits and a review owner before the pilot; the limits depend on the sensitivity and consequence of the workflow, so this guide does not prescribe benchmark values.
Phase 5: Approve, contain, or roll back
Expand only after the accountable owners review the evidence and sign off on data scope, access tests, freshness, failure patterns, and operating workload. Keep the previous configuration and a tested procedure for disabling the new source or connector and restoring compatible mappings. Preserve current authorization decisions and never re-enable revoked access. Verify that the existing team’s workflow meets its baseline after recovery.
Stop or roll back the pilot if a user can access restricted content; if revocation does not take effect; if citations or relations expose denied material; if cross-team terminology causes a consequential wrong answer; if source updates are not reflected within the agreed freshness window; or if failures or review hours exceed the pre-agreed operating limits. Record the incident, contain the affected source or scope, correct the cause, rerun the relevant tests, and require the same owners’ approval before resuming.
Illustrative onboarding worksheet
Use this as a working register, not as a claim that every platform has the same configuration or that each row is already supported by a particular product.
| Workstream | Reuse from existing team | New-team decision or evidence | Accountable owner | Pilot exit evidence |
|---|---|---|---|---|
| Sources and connectors | Existing connector pattern, monitoring, refresh process | New sources, credentials, format coverage, update and deletion behavior | Source / integration owner | Sample content and updates verified; connector errors visible |
| Vocabulary and schema | Shared concepts, common metadata, proven mappings | Aliases, collisions, team-specific concepts, unresolved terms | New-team domain owner | Held-out queries retrieve and distinguish the intended meaning |
| Permissions | Identity integration and tested policy patterns | Trusted attributes, source scope, denied actions, revocation path | Security / access owner | Allowed and denied tests pass across answers and supporting material |
| Indexing and retrieval | Existing parser, chunking, embedding, filters, and evaluation harness | Differences in file types, language, structure, metadata, or retrieval scope | Search / platform owner | Freshness, answer support, and failures measured by team and query type |
| Operations | Incident process, dashboards, review cadence | New-team source steward, escalation, review capacity, approval | Service owner | Named owners accept workload and rollback procedure is exercised |
Fill in the source of truth for each decision, not just the configuration value. If an owner cannot explain how an attribute is populated, how a source deletion propagates, or who reviews an access failure, treat that item as unresolved rather than assuming the existing setup covers it.
When to reprocess content—and how much
Reprocessing needs depend on which parts of the representation or retrieval pipeline changed. A new connector with the same content format may only require indexing the new source. A parser change can alter extracted text; changed chunking can change passage boundaries and metadata attachment; a new embedding model or its settings can make existing vectors incompatible with new queries; and schema or metadata changes can affect filters, relations, or authorization scope. In those cases, identify which sources and derived representations are affected, then reprocess and validate that scope. If the change affects a shared parser, embedding space, or schema used by both teams, include both teams in the impact analysis and regression tests.
Do not rebuild everything automatically, and do not promise that no rebuild is needed. Compare old and new representations on representative documents, check whether unchanged content can remain valid, and document the reprocessing plan, expected duration, recovery approach, and acceptance checks before rollout. Re-indexing content also does not replace retesting permission enforcement, freshness, or answer behavior.
AKB architecture: verify the deployment mode
The current AKB repository describes PostgreSQL-native revisions as the default for new installations and Bare Git as a supported legacy path for existing deployments. It describes vaults as the unit of access control and knowledge organization, and documents REST API, Web UI, and MCP access surfaces. Its design philosophy states that external consumers can be wired to support curation and other workflows; do not assume that external curation or verification is automatically bundled into the core. Confirm the deployed version and configuration before applying repository-level descriptions to a specific installation.
This distinction matters when planning a rollout: do not describe all AKB data as Git-stored, or treat an existing Bare Git deployment as if changing the default automatically migrates it. Confirm the actual revision backend, permissions model, connector responsibilities, and reprocessing path with the deployment owner. The repository documents vault boundaries and access controls, but this is not proof that a deployment’s departmental policy, identity attributes, retrieval paths, caches, or revocation behavior meet a particular organization’s requirements; test those paths directly.
FAQ
Can a new team be added without rebuilding the knowledge system?
Sometimes the existing platform and configuration can be reused, but there is no universal no-rebuild answer. Inventory the new source formats, vocabulary, permissions, and retrieval needs. Reprocess the affected scope when parser, chunking, embedding, or schema changes make existing derived representations unsuitable, and regression-test shared changes against both teams.
Does ABAC mean existing policies stay unchanged for a new department?
No. NIST describes ABAC as evaluating subject, object, operation, and potentially environment attributes against policy. Existing rules may be reusable when the new team has appropriate trusted attributes and the rules apply to its resources and operations. New attributes, resources, risks, or obligations may require policy changes. NIST’s guidance describes an access-control methodology; it does not establish that AKB ships ABAC.
What should the pilot test before a wider rollout?
Use new-team questions and held-out existing-team questions. Test terminology collisions, answer support and citations, source freshness, failure patterns, and human review effort. Exercise denied access and revocation across snippets, citations, relations, search results, and cached responses—not only the final answer. Set acceptable limits and accountable reviewers before testing.
What is AKB’s current storage and access model?
The current AKB repository describes PostgreSQL-native revisions as the default for new installations, with Bare Git supported for legacy deployments. It describes vaults as access and knowledge boundaries, with REST API, Web UI, and MCP surfaces. Check the deployed version and configuration; do not assume every installation uses the default or that external curation is built in.
Plan a safe team rollout
Use a scoped pilot to validate sources, vocabulary, access boundaries, retrieval, and ownership before expanding to more teams.