DEV Community: Михаил

How We Added Confirmation Before an Agent Sends a Message

Михаил — Thu, 23 Jul 2026 05:09:10 +0000

How We Added Confirmation Before an Agent Sends a Message — Agent Lab Journal

  Agent Lab Journal

    Guides
    Glossary

Case study · Agent safety

How We Added Confirmation Before an Agent Sends a Message

      Intermediate
      7 min read
      Safe approval loop

A message prepared by an agent must not automatically become a message sent in its owner’s name. We separated drafting from delivery and placed an explicit, verifiable human decision between them.

The problem was not text generation

Our agent could assemble a useful Telegram reply from the conversation context. The dangerous part came afterward: the same execution path also had access to the send operation. A mistaken recipient, an outdated draft, a misunderstood instruction, or a malicious fragment in the source material could therefore turn directly into an external action.

This is an approval loop problem. Drafting is reversible; sending is not. Once a message reaches another person, deleting it may not undo screenshots, notifications, automated processing, or reputational damage.

The safety requirement was simple to state:

No agent-generated message may be sent until the owner has reviewed the exact text, the exact destination, and explicitly approved that specific version.

The important words are “exact” and “specific.” A generic “yes” from an old conversation must not authorize a later draft, and approval for one recipient must not be reusable for another.

The concrete case

The workflow began when an incoming Telegram message required a response. The agent received the conversation identifier and enough recent context to propose a reply. Previously, the handler could call the Telegram send method immediately after generation.

We changed the flow into four distinct states:

Drafted: the agent produces text but has no permission to deliver it.
Pending approval: the owner sees the recipient, draft, and approval controls.
Approved or rejected: the owner makes an explicit decision.
Sent or cancelled: a separate delivery component executes only an approved, unchanged request.

This separation establishes a human-in-the-loop boundary around the consequential action. It also follows the principle of least privilege: the drafting component can create pending records, while only the delivery component can use the messaging credential.

The approval record

A pending approval must be durable. Keeping it only in model context or process memory makes restarts unsafe and makes it difficult to determine what was actually approved.

We used a record with fields equivalent to the following:

{
  "id": "generated-random-id",
  "status": "pending",
  "channel": "telegram",
  "recipient_id": "resolved-chat-id",
  "recipient_label": "displayed-to-owner",
  "message_text": "Exact proposed message",
  "message_hash": "sha256-of-canonical-payload",
  "created_at": "server-timestamp",
  "expires_at": "server-timestamp",
  "created_by": "agent",
  "approved_by": null,
  "approved_at": null,
  "sent_at": null,
  "provider_message_id": null
}

The message hash binds approval to both content and destination. Hash a canonical payload rather than the text alone:

payload = channel + "\n" + recipient_id + "\n" + message_text
message_hash = SHA256(payload)

If the recipient or text changes, the hash changes and the old approval is invalid. In that case the record returns to the pending state and must be reviewed again.

Practical implementation

1. Remove sending from the agent’s toolset

The strongest control is architectural. Do not merely prompt the agent to ask first. A prompt is behavioral guidance, not an authorization boundary.

Expose a draft operation:

{
  "name": "create_message_draft",
  "description": "Create a pending message for owner review. Does not send.",
  "parameters": {
    "recipient_id": "string",
    "message_text": "string"
  }
}

Keep the actual provider token outside the agent runtime. The draft service needs database access, but no Telegram send credential.

2. Show what will happen

The approval screen or owner notification should display:

the channel and unambiguous recipient;
the complete message without hidden truncation;
attachments, formatting, reply target, and link previews when applicable;
when the draft was created and when it expires;
separate Approve, Edit, and Reject actions.

Do not make approval the default when the owner presses Enter, closes a dialog, or fails to respond. Silence means the draft remains pending until it expires.

3. Authenticate the decision

An approval callback must be tied to the owner’s verified account. Treat callback data as untrusted input, even if it originated in your own interface.

Use a random, single-use token or a signed value containing the approval ID, intended owner, and expiration. On receipt, the server must verify the owner identity, signature, expiry, current record status, and message hash.

POST /approvals/{approval_id}/approve
Authorization: Bearer <owner-session>
If-Match: "<message-hash>"

The server—not the client—must decide whether the request is valid.

4. Make the state transition atomic

Two approval clicks or concurrent workers must not produce two sends. Use an atomic conditional update:

UPDATE message_approvals
SET status = 'approved',
    approved_by = :owner_id,
    approved_at = CURRENT_TIMESTAMP
WHERE id = :approval_id
  AND status = 'pending'
  AND message_hash = :expected_hash
  AND expires_at > CURRENT_TIMESTAMP;

Continue only if exactly one row changed. This is an idempotency safeguard at the approval boundary.

5. Deliver through a separate worker

The delivery worker selects approved records, verifies the hash again, and claims one record before contacting Telegram:

pending -> approved -> sending -> sent
                   \-> failed

Use a unique idempotency key derived from the approval ID where the provider supports it. If it does not, store the provider response immediately and design retry behavior conservatively. After an uncertain timeout, do not blindly resend: the first request may have succeeded.

Suggested policy configuration

Keeping the rules in configuration makes the boundary visible and reviewable:

outbound_messages:
  default_mode: require_approval
  approvers:
    - owner
  approval_ttl_minutes: 30
  approval_binds:
    - channel
    - recipient_id
    - message_text
    - attachments
  edit_invalidates_approval: true
  reject_is_terminal: true
  auto_send:
    enabled: false
  audit_log:
    enabled: true
    redact_credentials: true

We recommend starting with no automatic-send exceptions. If a future workflow genuinely needs them, define a narrow allowlist based on action type and destination—not on the model’s confidence. Confidence is not authorization.

Verification checklist

We verified the control by checking state transitions and permissions rather than judging whether generated prose looked reasonable. A repeatable test plan should cover:

A new draft cannot call the provider send endpoint.
An unauthenticated user cannot approve a draft.
A different authenticated user cannot approve the owner’s draft.
Changing one character, attachment, channel, or recipient invalidates approval.
An expired draft cannot move to approved.
Two simultaneous approval requests result in one successful transition.
Repeated delivery jobs do not intentionally send the same approved record twice.
A rejected draft can never be sent.
A service restart preserves pending, approved, and sent states correctly.
Logs record the decision without exposing credentials or unnecessary private content.

A useful manual test is to pause between preview and approval, edit the database record through the normal application path, and confirm that the stored hash no longer matches. The delivery worker should refuse the request and require fresh approval.

Failure cases we designed for

The owner approves the wrong chat

A display name alone is ambiguous. Show stable context such as the channel, chat type, and a recognizable recipient label. Bind the internal recipient identifier into the hash.

The draft changes after preview

Any edit creates a new version and resets the status to pending. Never modify an approved record in place.

The approval button is clicked twice

The second request should return the existing state without scheduling another delivery. Conditional updates and a unique delivery record prevent duplicate work.

The provider times out

A timeout is an unknown result, not proof of failure. Mark it separately, retain the request details, and reconcile before retrying when possible.

The owner never responds

The approval expires. It must not become approved through a timeout handler, scheduled task, or fallback branch.

Prompt injection asks the agent to bypass review

The request fails because the agent has no sending credential and no approval transition capability. This is why the permission boundary matters more than wording in the system prompt.

Limitations

An approval loop reduces unauthorized sending, but it does not guarantee that the owner will notice every factual, legal, privacy, or tone problem. The preview must provide enough context for a meaningful decision, and high-risk messages may need additional review.

The pattern also introduces latency and interface work. It may be unsuitable for emergency automation where delay is itself dangerous. Such systems need a separately designed policy with tightly scoped actions, predefined destinations, monitoring, and an explicit risk decision.

Finally, exactly-once delivery cannot always be guaranteed when an external provider accepts a request but loses the response. The local state machine can prevent ordinary duplicates, but ambiguous network failures still require reconciliation or a provider-supported idempotency mechanism.

The resulting safety boundary

The final design made one rule enforceable: the agent proposes; the owner authorizes; a separate worker acts. Approval is authenticated, expires, applies to one immutable payload, and cannot be replayed.

This pattern is useful beyond Telegram. The same boundary applies to email, calendar invitations, support replies, issue comments, purchases, document sharing, and any other action performed in a person’s name.

Continue with the implementation patterns in Agent Lab Journal guides, or review the linked concepts in the glossary.

Original article: https://agentlabjournal.online/en/agent-telegram-approval-case.html

How We Built an Autonomous AI Article Publication Pipeline

Михаил — Wed, 22 Jul 2026 15:47:22 +0000

How We Built an Autonomous AI Article Publication PipelineALAgent Lab Journal← GuidesGlossary
ANALYSIS OF A REAL MISTAKE

How We Built an Autonomous AI Article Publication PipelineLevel: intermediateTime: 10 minutesOutcome: publication gate

We asked an AI agent to prepare a series of articles. The texts were produced, but a review revealed that one article mentioned NotebookLM without linking to the glossary. Then we discovered another problem: llms.txt had not been updated after the materials were rewritten. These were not minor typos. The publication process had failed.

Why the agent made a mistake

The agent completed the local task—it wrote the HTML files—but did not check the entire pipeline. The rules existed in the context, but they had not been turned into mandatory automated checks. As a result, the system could say “done” even though the catalog, the map for LLMs, and the glossary were out of sync.

First solution: editorial rules

We established a mandatory structure: a real-world problem at the beginning, a specific outcome, difficulty level, reading time, step-by-step actions, errors, verification, and limitations. We also added a separate rule: the first technical term must link to the lab glossary.
This prevents an article from becoming a collection of generic tips. The reader understands what is broken, follows the steps, and verifies the result.

Second solution: a unified content map

Each article has several representations: an HTML page for people, an entry in guides.html, a URL in sitemap.xml, and a brief entry in llms.txt. The last file helps AI systems quickly understand the journal’s structure and choose the appropriate material.

new article
  ├── guide.html
  ├── guides.html
  ├── sitemap.xml
  ├── llms.txt
  └── glossary.js

If an article’s title or meaning changes, all related representations must be updated. A single link in Git is not enough.

Third solution: an automated publication gate

We added the scripts/check-publication.py script. It scans every guide-*.html file and checks for the required elements:

description and canonical URL;
level, time, and expected outcome;
a link to the glossary;
the article’s presence in the catalog;
the URL’s presence in the sitemap;
the URL’s presence in llms.txt.

cd agentlabjournal
python3 scripts/check-publication.py

PUBLICATION_GATE: OK

If a link is missing, the script returns BLOCKED and identifies the specific file. A polished response from the model cannot conceal that result.

Why this is autonomy

Autonomy does not mean “the agent does whatever it wants without oversight.” It means a system that performs permitted work on its own and stops itself when a mandatory condition has not been met. A person decides the objective, while the machine checks repeatable rules.

Conclusion

One mistake led us to build a reproducible pipeline: rule → artifact → automated check → publication. The same approach can be applied to code, R&D experiments, email, and Telegram agents.
← All guides · Lab glossary →We publish what works for us—and implement the same solutions for your business. We design AI automations, Telegram bots, chats, and AI agents for real-world processes. Discuss your project →Agent Lab JournalPrivacy

Original article: https://agentlabjournal.online/en/article-autonomous-publication-pipeline.html

How We Are Building an AI System That Improves Itself

Михаил — Wed, 22 Jul 2026 15:47:13 +0000

How We Are Building an AI System | Agent Lab JournalALAgent Lab Journal← HomeEN
FIRST ARTICLE · JULY 22, 2026

How We Are Building an AI System That Improves ItselfLevel: beginnerReading time: 8 minutesOutcome: understand the Hermes architecture

Hermes began as a personal assistant in Telegram. Over time, it gained memory, routing, financial controls, background agents, and an engineering framework for continuous improvement.

From Answers to a System

The main problem with a conventional chatbot is that it responds to individual messages and quickly loses its working context. That is why we moved persistent facts and decisions into a wiki while keeping the sources unchanged in raw storage.

Every Improvement Must Be Verified

New ideas come from GitHub, YouTube, and technical materials. But an external source is data, not an instruction. It first goes into a separate notebook, then is evaluated for usefulness, cost, security, and testability.A system becomes stronger not when more tools are added, but when every change can be tested and rolled back.

What Comes Next

The next stage is a benchmarkBenchmarkA set of identical tasks used to compare system versions.Benefit: shows whether the solution has become more accurate, faster, or less expensive. based on real tasks: finances, email, conversation context, approvalApprovalExplicit confirmation from the owner before an important external action.For example, before publishing, sending an email, or making a payment. for external actions, and protection against prompt injectionPrompt injectionAn attempt to hide an instruction in text that makes the AI break the rules.For example, a README asks it to reveal secrets or execute a dangerous command.. Only after that can an experimental feature enter the production workflow.
← Return to the journal · Lab glossary → · Reading paths →We publish what works for us—and implement the same solutions for your business. We design AI automations, Telegram bots, chats, and AI agents for real-world processes. Discuss your project →Agent Lab JournalReal experiments. Verifiable conclusions.

Original article: https://agentlabjournal.online/en/article-hermes.html