Bringing BotsTeam into Core: Consolidating Our AI-Assisted Development Tooling

Over the last months, several internal tools have gradually emerged around our development workflow. Some started as experiments, others evolved into infrastructure that we now use across multiple projects.

Two of those projects are Core and BotsTeam.

Core has become the foundation for analysing our repositories, checking whether projects follow our standards, collecting deterministic evidence, and producing structured reports that can later be consumed by systems such as WatchTower.

BotsTeam approached the problem from another direction. Instead of deterministic checks, it introduced a collection of executable LLM-powered bots capable of analysing Git history, reviewing issues, suggesting tests, planning work, improving reports, and interacting with external services.

Both projects are useful.

The problem is that they have increasingly started solving different parts of the same workflow.

It is therefore time to bring them closer together.

Two Projects, Two Different Responsibilities

Core is intentionally conservative.

Its audit pipeline is based primarily on Python's standard library and produces predictable, schema-validated results. The goal is not to make decisions using AI, but to collect facts about a project.

For example, Core can determine things such as:

• which technologies a repository uses;
• whether expected Drupal modules are installed;
• whether project configuration follows our conventions;
• whether frontend assets are correctly configured;
• whether CI, testing, documentation, and project tooling are present;
• and which criteria currently pass or fail.

BotsTeam is almost the opposite.

Its main purpose is interpretation and assistance.

Bots can take information from repositories, Git history, GitLab or GitHub and use LLMs to produce higher-level output such as:

• summaries of recent development;
• suggested tests;
• sprint plans;
• improved issue descriptions;
• reports;
• development recommendations;
• and potentially coordinated conversations between specialized bots.

These responsibilities are complementary.

Core answers:

What is actually true about this project?

Bots answer:

Given those facts, what should we understand, communicate, or do next?

That distinction is important because it also defines how the projects should be merged.

Why Not Simply Copy BotsTeam into Core?

A complete repository merge would be easy technically, but architecturally it would be the wrong solution.

Core deliberately keeps its main runtime lightweight. BotsTeam requires considerably more infrastructure, including LLM providers, GitLab and GitHub clients, CLI libraries, reporting libraries, and other third-party dependencies.

Making those dependencies part of Core's normal audit pipeline would fundamentally change what Core is.

There is also functionality inside BotsTeam that does not belong in Core at all.

BotsTeam currently contains experiments around:

• personal productivity bots;
• voice interfaces;
• Slack integration;
• PageSpeed analysis;
• report export;
• and its own interactive dashboard and API.

Some of those ideas are useful, but they should not automatically become responsibilities of Core.

The goal should therefore not be:

BotsTeam disappears into Core.

Instead:

The parts of BotsTeam that support our shared development workflow become an optional subsystem of Core.

An Optional Bots Workspace

The proposed architecture introduces a dedicated bots/ workspace inside Core.

Conceptually, Core would then contain two execution environments.

The first remains the existing deterministic audit pipeline:

Repository    ↓ Core analyzers    ↓ Criteria evaluation    ↓ project-report.json    ↓ WatchTower

The second would be optional:

Core project data    ↓ Bots workspace    ↓ LLM-assisted analysis    ↓ Markdown reports / recommendations / actions

The distinction is deliberate.

Running Core should never require an LLM.

Running an audit should never require an OpenAI, Anthropic, Gemini, GitLab, or GitHub token.

The bots become an additional capability rather than a dependency of the audit system.

This separation also gives us a useful architectural rule:

Deterministic evidence remains authoritative. AI interprets that evidence.

One Project Registry

One of the clearest examples of unnecessary duplication today is project configuration.

Core already maintains a project registry describing the repositories it manages.

BotsTeam has another one.

The two registries contain overlapping information such as:

• project name;
• repository path;
• production URL;
• GitLab or GitHub information;
• and project-specific configuration.

Maintaining both inevitably creates drift.

The merge therefore gives Core's registry a second responsibility: it becomes the shared source of project information for bots as well.

Bot-specific configuration can live in an optional section:

{  "name": "example-project",  "source": {    "path": "/path/to/project"  },  "bots": {    "tracker": {      "gitlab_project_id": 123    }  } }

Secrets still do not belong there.

API keys, tokens, and webhook URLs should continue to live in environment variables.

The registry only describes how a project connects to those services.

One Definition of Each Bot

There is another duplication that is even more interesting.

Core already contains bot specifications.

Inside docs/bots/, roles can be described through files such as:

BOT.md OUTPUT.template.md

These describe what a bot should do, how it should behave, and what its output should look like.

BotsTeam, however, currently defines many of those instructions directly inside Python code as system prompt strings.

This means we effectively maintain two definitions of the same role.

The merged architecture can eliminate that duplication.

Executable bots should load their behaviour from the same specifications that humans or external agents can use.

For example:

docs/bots/qa-advisor/BOT.md                    ↓             executable qabot                    ↓            structured output

This gives us several advantages.

Prompt changes become normal documentation changes that can be reviewed in Git.

The bot contract becomes independent from its execution mechanism.

And the same role can eventually be executed by different systems without rewriting its definition.

In other words:

The specification describes the role. The executable bot implements it.

Facts In, Narrative Out

The most interesting integration point is probably Core's canonical project report.

Today, some bots independently inspect repositories to discover information that Core already knows.

That is unnecessary.

If Core has already determined the technology stack, project configuration, failing criteria, repository status, and other facts, bots should be able to use those results directly.

The flow becomes:

Repository    ↓ Core    ↓ project-report.json    ↓ Bot    ↓ Explanation / recommendation / plan

This creates a clear boundary.

The canonical report contains evidence.

Bot output contains interpretation.

The bot should not silently modify the canonical report, because doing so would mix deterministic audit information with probabilistic AI output.

Instead, bot reports can live separately:

reports/ └── bots/    └── project-name/        ├── git-historian/        ├── qa-advisor/        └── issue-analyst/

Those reports can still be displayed in Core's dashboard without becoming part of the WatchTower audit payload.

Starting with the Bots That Add the Most Value

Not every existing bot needs to move.

The first candidates are the ones directly related to software development.

Git history analysis

The existing Git bot can become something closer to a Git Historian.

Instead of simply collecting commit information, it could combine repository facts and Git history to explain what changed during a period of development.

That information could later feed other roles such as a feature presenter or merge-request generator.

QA assistance

The QA bot already implements functionality that Core's software engineering specifications identify as useful: analysing tests, suggesting coverage, and generating test scaffolding.

This is a strong candidate for integration.

The important distinction is that proposing tests is safe by default.

Writing generated tests into a repository is not.

Write operations should therefore require explicit activation.

Issue analysis and planning

The project-management bot also contains useful functionality for analysing issues and preparing sprint plans.

Some of its responsibilities overlap with functionality being developed elsewhere, particularly in WatchTower.

That overlap gives us an opportunity to clarify ownership rather than simply copy the implementation.

Core can provide project context.

Bots can draft or analyse.

WatchTower can eventually manage persistent workflows and reviewer approval.

AI Should Not Get Write Access by Default

The introduction of executable bots makes Core's trust model increasingly important.

Core is essentially read-only.

There are specific operations that can modify repositories, but they are explicit.

Bots should follow the same rule.

Commands that create issues, update trackers, or generate files should follow a pattern such as:

analyse    ↓ show proposed changes    ↓ preview    ↓ explicit confirmation    ↓ apply

A project should also be able to explicitly opt into writable bot operations.

This is particularly important because LLM-assisted automation changes the cost of mistakes.

Generating a suggestion is cheap and reversible.

Automatically editing twenty repositories is not.

The Dashboard Should Remain Read-Only

BotsTeam currently has its own dashboard and API.

Some of its functionality allows configuration changes, bot execution, project management, and even environment configuration.

That architecture should not move into Core.

Core's existing dashboard is intentionally simple and read-only.

A better approach is to add a Bots section that displays the latest reports produced by each bot.

Running bots can remain a command-line operation.

For example:

make bots-run

or eventually:

make bots-run BOT=qa-advisor PROJECT=example

This keeps the browser interface safe while still making bot output easy to explore.

What Should Stay Outside Core

A merge is also an opportunity to define boundaries.

Some components of BotsTeam should remain outside the shared development platform.

Personal productivity bots are one example. Journal, task, habit, and note workflows may still be useful experiments, but they have a completely different data boundary from client development projects.

Voice functionality also has little reason to become part of Core.

PageSpeed analysis is another case where moving code would add duplication rather than remove it. WatchTower already has a natural responsibility for monitoring deployed sites and collecting external audit information.

Report export is similar. Generating branded PDFs or presentations is better suited to WatchTower, where reports are persisted and presented, than to the local audit engine.

The purpose of merging is not to maximize the size of Core.

It is to reduce unnecessary boundaries while preserving useful ones.

A Staged Migration

Instead of moving thousands of lines of code at once, the integration should happen in phases.

The first phase should not move code at all.

BotsTeam should first consume Core's project registry.

That alone removes one source of duplication and tests whether the two systems can share configuration cleanly.

The next step is to migrate bot definitions to the shared docs/bots/ specifications.

Only after those contracts are stable should executable code move into Core's bots/ workspace.

The broader sequence looks roughly like this:

1. Stabilize the current BotsTeam codebase.
2. Share Core's project registry.
3. Move bot prompts and output contracts into docs/bots/.
4. Create the isolated bots/ workspace.
5. Move the work-oriented bots.
6. Allow bots to consume Core's canonical reports.
7. Display bot reports in the Core dashboard.
8. Introduce safe, explicitly enabled mutation.
9. Evaluate whether a multi-bot orchestrator is still useful.
10. Retire or repurpose the original BotsTeam repository.

Each step should remain independently useful.

If we stop after step three, we have still removed significant duplication.

That makes the migration considerably safer than a traditional repository merge.

Core as a Local Development Platform

This change also says something more fundamental about what Core is becoming.

Originally, Core could be understood primarily as an audit tool.

That definition is becoming too narrow.

Across our projects we increasingly need shared tooling for:

• repository inspection;
• project normalization;
• QA;
• frontend checks;
• documentation;
• Git operations;
• automated analysis;
• AI-assisted development;
• and integration with WatchTower.

Core is gradually becoming the local development platform behind those workflows.

WatchTower plays a complementary role on the deployed side.

A useful architectural distinction is therefore emerging:

                Development environment                    CORE                     │        ┌────────────┼────────────┐        │            │            │     Audits       Tooling        Bots        │            │            │        └────────────┼────────────┘                     │                     ▼              Structured evidence                     │                     ▼                 WATCHTOWER          Monitoring / history / reports

Core understands repositories locally.

WatchTower understands projects over time.

Bots can operate between both layers, using deterministic information as context while adding interpretation and assistance.

That seems much more valuable than maintaining a separate AI-bot platform beside them.

Suggested Next Steps

Before implementing the full merge, there are a few architectural questions worth resolving.

The first is LLM provider strategy.

BotsTeam currently supports multiple providers. That flexibility is useful, but it also adds dependencies and configuration complexity. We should decide whether provider independence is an explicit architectural requirement or simply something inherited from experimentation.

The second is ownership of issue automation.

Both bots and WatchTower are moving toward analysing and improving project issues. We should define one workflow rather than allow two implementations to evolve independently.

The third question is where AI-generated reports should eventually live.

Keeping them locally under reports/bots/ is a good starting point, but useful reports may eventually deserve persistence in WatchTower as explicitly AI-generated artifacts.

Another interesting next step would be to establish a small bot protocol.

Instead of every bot inventing its own CLI and output behaviour, Core could define a common contract such as:

input:  project  canonical project report  role specification  optional user context output:  Markdown report  structured metadata  proposed actions

With that contract in place, adding a new bot becomes much simpler.

Finally, we should resist the temptation to introduce orchestration too early.

A system where bots automatically call other bots sounds attractive, but the real architectural value comes first from making individual roles predictable, testable, and grounded in reliable project data.

Once that foundation exists, orchestration becomes considerably easier.

Conclusion

The most useful outcome of merging BotsTeam and Core is not having fewer Git repositories.

It is having fewer competing sources of truth.

One project registry.

One definition of each bot role.

One deterministic source of project facts.

One place for local development automation.

And a clear separation between evidence and AI interpretation.

Core should remain predictable.

Bots should remain optional.

WatchTower should remain the system that observes projects over time.

Connecting those three responsibilities gives us something much more interesting than a collection of scripts: a development platform where deterministic automation and AI assistance can work together without confusing their roles.