ContextForge: How to Build a Bounded and Verifiable Context for Coding Agents

Kirill — Sat, 22 Aug 2026 12:38:30 +0000

In Brief

Large agents are good at writing code, and many work well with context, but in large projects, context often bloats significantly, rendering local models almost useless, and large ones consume so much context that they can even hit limits! But that's not the only problem: sometimes you need to fix one small bug, but the agent spends more than half of its context just analyzing the project!

And so three problems arise:

The context bloats;
It accumulates things that are unnecessary for the task;
Local models stop working properly altogether.

I created a project that solves these problems.

ContextForge is a separate layer between the repository and the coding agent. It doesn't write code: it analyzes the project, selects a limited set of the required context, and returns the result in the form of your prompt + context.

I recently released the project into open beta testing; you can find it on GitHub at the end of the article!

Why do we need a separate context layer at all?

Let's say we assign a task to an agent.

A human already knows where to look. But for the agent, the whole chain of thought starts all over again:

What project is this?
What version?
Do the source files match the git repository?
Where is the main file?
What function is this?
Which variables and functions already exist, and which ones need to be written?
And so on.

So, before writing the code, the agent performs one more task: scanning the repository.

And maybe my wording is a bit crude (in addition to scanning, the agent is also thinking about how to test, etc.), but scanning a repository is a problem that grows as the repository grows and consumes more and more tokens with each request.

Bottom Line

Initially, I wanted to take one thing away from the agent—context management.

Currently, the project is still in beta (or even alpha) status. Context may be generated incorrectly, and the local model may introduce hallucinations into the context (and not fix them during testing). But for the most part, the project is already working.

If you don't mind, I'd love to get a review and hear your ideas and concerns!

Telegram Has Rich Messages Now — So I Built a Markdown Workflow for Them

Kirill — Thu, 16 Jul 2026 12:19:02 +0000

Telegram messages have traditionally been fairly simple.

You could send text, apply basic formatting, attach media, or use a few special message types such as polls. More complex posts usually had to be split across multiple messages or assembled manually with separate media groups.

That changed with Telegram's new rich messages.

Rich messages can contain structured blocks such as:

section headings;
paragraphs;
quotations;
collapsible details;
mathematical expressions;
dividers;
inline images and videos;
collages;
slideshows;
and more!

Instead of treating a post as one text string followed by attachments, Telegram can now represent it as a sequence of content blocks.

This makes a Telegram message feel much closer to a small article.

Two related Telegram updates

There are two parts of this change that are easy to confuse.

In June 2026, Telegram introduced rich-text messages for bots. The Bot API gained structured rich-message objects that bots could use to send long, block-based posts.

In July 2026, Telegram added a visual rich-text editor to its official clients. The editor supports headings, lists, tables, quotations, code blocks, inline media and messages containing more than 32,000 characters.

However, Telegram currently makes the visual editor available only to Telegram Premium users.

The underlying rich-message format is not limited to manually composed Premium messages. Bots can construct rich messages through Telegram's official API.

That distinction creates an interesting opportunity: alternative editors can be built on top of the official bot interface.

Why this matters

The new format is useful for more than decorative channel posts.

A structured message can represent:

a project announcement;
release notes;
technical documentation;
an event schedule;
a tutorial;
a community guide;
a FAQ;
a product changelog;
a formatted news post;
a collection of images with commentary.

Previously, creating this kind of content in Telegram often required several separate messages. The result was harder to edit, forward and read as one document.

Rich messages make the structure explicit.

A heading is a heading. A list is a list. A collage is a content block rather than a loosely associated group of attachments.

The current accessibility problem

The feature itself was generally received as useful, but the Premium restriction generated a predictable discussion.

In a recent discussion on r/Telegram, users questioned why basic formatting such as lists and richer posts required a subscription. Some Premium subscribers also argued that formatting is not inherently an advanced or resource-intensive feature.

This resembles the reaction to Telegram checklists. When collaborative checklists were introduced, users reported that non-Premium members could see a checklist but could not necessarily interact with it in the way group members expected.

The issue is not simply that Telegram Premium exists. Premium subscriptions fund Telegram and include many optional capabilities.

The practical problem is that structured content is especially useful in collaborative environments:

community channels;
open-source projects;
student groups;
small teams;
public announcements.

In those environments, requiring every author to use the same paid editor can make adoption less convenient.

Bots provide another interface to the same platform capabilities.

A Markdown-based approach

I wanted to test whether rich Telegram posts could be created without building another large visual editor.

Markdown was a natural input format because it is:

readable as plain text;
familiar to developers;
easy to store in Git;
portable between editors;
suitable for templates;
straightforward to generate programmatically.

The resulting workflow is intentionally simple:

Write a post in Markdown.
Send the text or a UTF-8 .md file to a Telegram bot.
Let the bot parse the document.
Convert supported Markdown extensions into Telegram rich-message blocks.
Preview and publish the resulting message.

The project is called Amethyst-Post-Bot.

It is not a modified Telegram client and it does not imitate user actions. It uses Telegram's official bot APIs to construct messages from structured blocks.

You can check out my implementation on GitHub: https://github.com/rassvetteam/Amethyst-Post-Bot
And support me, too! https://www.patreon.com/waterflane_dev

DEV Community: Kirill