Inspiration
As a Solopreneur, Independent AI trainer and consultant, I face constant challenge in staying current in a fast-moving field. "Training the trainer" takes real research time every week, and turning that research into teachable content takes even more. Most tools give you information — a list of articles, a pile of search results — and leave the actual synthesis to you. I wanted an agent that closes the gap and serve me in 2 ways: As a trainer, I want curated content from a researcher, who researches, prioritizes, fine tunes, synthesizes an serves me the content that i would have to learn and curated content that are ready to be reviewed and published to my learners community and future training content ideas.
What it does
A Strands multi-agent system researches a given topics' trends and tooling/framework trends every week, remembers what it's already reported so only genuinely new findings surface, and classifies each finding by signal strength — strong if corroborated across multiple sources, early if from just one. From that, it drafts real content: a ready-to-edit LinkedIn post built from the strongest finding, and 1–3 training-module ideas with learning objectives and key points already outlined. The digest reaches the trainer automatically and privately over Telegram. Publishing anything to a student-facing channel is a deliberate, separate, manually-triggered action — the trainer is always the one who decides what actually goes out.
How we built it
We built it iteratively: a single tool, then multiple tools, then the multi-agent orchestrator, then a memory/dedupe layer, a fully local/GitHub-Actions that integrates with Telegram to provide the curated content to the user at their fingertips.
An orchestrator agent delegates to two specialist sub-agents (job-market and tooling-trend), each with its own tools and a Steering-enforced per-tool call budget. A separate, tool-less formatter agent turns the raw research into a typed digest via Strands' structured output. Everything runs as plain Python against Groq's API (via Strands' OpenAI-compatible model interface), scheduled and triggered through GitHub Actions — no server to run or maintain. Delivery is push-only Telegram messages; a second, always-manual workflow is the only path to the student channel.
Challenges we ran into
A misdiagnosed retry setting : We initially set max_attempts=1 on ModelRetryStrategy to stop a tool from retrying after a bad API call — only to later realize that setting only governs model-throttling retries, not tool errors, and had been silently disabling real rate-limit protection the whole time. A genuine infinite-loop bug : a sub-agent kept calling the same search tool trying to "open" a specific job posting — a capability that tool never had. Fixed properly with Strands' Steering plugin, which gives the model real feedback about why it was stopped, not just a hard cutoff.
A subtle grounding issue: a sub-agent named specific tools (e.g. monitoring products) that weren't actually present in its search results — confident-sounding elaboration beyond the evidence. We built a manual debug flag to catch this and tightened prompts to constrain it.
A real API-level contradiction: calling structured_output() on an agent that still had tools attached failed outright on Groq, because structured output internally forbids tool calls while the agent's own instructions told it to delegate. Fixed by splitting research (tools allowed) and formatting (a separate, tool-less agent) into two calls.
Accomplishments that we're proud of A genuinely multi-agent, using Strands' orchestration, Steering, structured output, retry handling, and native observability as real, load-bearing parts of the design. Every one of the challenges above was root-caused and fixed properly, not worked around — several of them turned into permanent regression test cases. A complete, free, serverless pipeline: scheduled research, drafted content, and Telegram delivery, running entirely on GitHub Actions' free tier with no infrastructure to maintain. A deliberate human-in-the-loop design where approval isn't a feature bolted onto the agent, but an architectural boundary between drafting and publishing. This removes the stress of users being always "on" and provides them liberty to work at their comfort time and take things further.
What we learned
A simple synergy of tools can help improve business growth by intelligently channelizing the energy in activities that are of immense value. Strands' structured_output() and its tool_choice behavior have real, specific constraints worth understanding before assuming an agent with tools can also produce structured output in the same call. Not every fix that "makes an error go away" is the right fix — the retry_strategy misconfiguration taught us to verify which failure mode a mechanism actually covers before trusting it silently.
Human-in-the-loop doesn't have to live inside an agent's own reasoning loop — a separate, manually-triggered action can be just as real a gate, and is often simpler and more auditable.
What's next for ResearchAssistant
- An automated grounding check (extending the Steering policy's steer_after_model hook) to catch ungrounded elaboration structurally, not just via manual review.
- A broader evaluation/observability layer (explored separately using Arize Phoenix + DeepEval) to benchmark agent behavior over time, not just spot-check it.
- Feedback Agent addition- Effective user feedback loop via channels closer to the user than relying on Githubactions
- Complete E2e operation from telegram or other channels
- Expanding beyond Telegram to other channels, and making the personal digest side interactive (ask follow-up questions), not just a one-way weekly push.
Log in or sign up for Devpost to join the conversation.