TGViewer
annFlow annFlow @annsflow · 33 subscribers
Post #149 35
Почему полная автономия оказалась слабее управляемой автономии

Сначала мне казалось, что хороший результат в таком проекте, это полная автономия.

Чтобы система сама искала вакансии, сама принимала решения, сама отправляла отклики и вообще не звала меня в процесс.

На практике это оказалось слабой идеей.

В реальной среде полная автономия быстро превращается в шум, риск и потерю качества.
Чем сложнее форма отклика, тем опаснее система, которая не умеет вовремя остановиться.

Поэтому проект пришёл к другой модели: не к слепому автопилоту, а к управляемой автономии.

Если вакансия идет по понятному сценарию, проект обрабатывает её сам: находит по нужному search mode, подбирает подходящее резюме, анализирует текст вакансии, собирает персональное сопроводительное, проходит простой apply-flow и отправляет отклик.

Если уверенность заканчивается, он не пытается дожать путь любой ценой, а переводит кейс в Telegram-first handoff.

Это видно даже по рабочей конфигурации проекта:


search_mode = 7
browser_submit_mode = "auto_with_handoff"
active_profile = "24x7"
target_applies_per_day = 20
max_submits_per_run = 2
max_submits_per_hour = 3
Approve questionnaire


search_mode = 7 у меня означает не абстрактную цифру, а конкретный поисковый сценарий: AI/LLM-направление для Москвы и Петербурга.
browser_submit_mode = "auto_with_handoff" означает: простой путь система закрывает сама, сложный уводит в handoff.
active_profile = "24x7" переводит проект в режим регулярной эксплуатации.
target_applies_per_day = 20 задаёт дневную цель.
max_submits_per_run = 2 не даёт одному прогону превращаться в агрессивный залп.
max_submits_per_hour = 3 ограничивает темп, чтобы система жила долго и предсказуемо.
Approve questionnaire фиксирует главный принцип всей модели: там, где уверенность заканчивается, решение остаётся за человеком.

Проект работает вручную и по расписанию, идёт по нужным search modes, использует отдельные runtime profiles для окна запусков, pacing и квот, делает нужное количество откликов в день и сам проходит happy path там, где решение уже достаточно надёжно.

Telegram в этой модели перестал быть просто уведомлением.
Он стал внешним контуром управления.

Туда уходят uncertain cases, questionnaire review, handoff и approve.
Незавершённые случаи живут не в случайных вкладках, а в backlog и state.
Следующий run умеет их подхватывать, проверять статус и продолжать с нужной точки.

Так проект пришел не к ручной работе и не к слепой автономии, а к управляемой автономии, которая живёт в ежедневном режиме и подключает меня только там, где качество важнее автоматизма.

Полная автономия перестала быть целью.

Целью стала система, которая умеет сама делать регулярную работу и зовёт человека только в тех точках, где это действительно нужно.

Оглавление темы 📌
Навигация по проектам канала 📍
Все проекты 🎶

#HHApply@annsFlow

💻 annFlow
Telegram annFlow Как я построил систему автооткликов, или Как превратить поиск работы в форму порядка ● Автоматизация отклика как ответ на асимметрию рынка ● Как бот сравнивает меня с вакансией и собирает отклик под нее ● Почему закрытие соискательского API не убило проект…
More from @annsflow
  1. Sep 24, 2026LiveContext в реальном разговоре. На видео я разбираюсь с претензией по недоставленному за…
  2. Sep 21, 2026Как LiveContext разделяет мой голос и голос собеседника Чтобы LiveContext мог понимать раз…
  3. Sep 16, 2026Почему мне оказалось недостаточно просто сохранять разговоры В VoxBase я решал проблему то…
  4. Sep 15, 2026Как я построил LiveContext, или Как связать живой разговор с памятью проекта ● Почему мне…
  5. Sep 14, 2026annFlow pinned a video
  6. Sep 14, 2026Самая неожиданная вакансия, которую нашел мой бот Моя система постоянно сама ищет вакансии…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →