Sidekick

• 

• 

  Architecture

Inspiration

As an engineer, I found myself starting every day the same way: opening 10+ browser tabs to piece together my daily plan. Calendar for meetings, Gmail for urgent emails, JIRA for tasks, PagerDuty for overnight incidents, AWS console for infrastructure alerts. By the time I had a complete picture, 30 minutes were gone and my first meeting was starting.

The "aha moment" came during a particularly chaotic morning when a critical production incident overlapped with an internal demo. I was frantically switching between Confluence runbooks, AWS CloudWatch, and Slack trying to coordinate the response. I thought: "Why can't an AI assistant do this aggregation for me?"

The tools on the market are costly and require deep integrations. However, what I need is something that uses my own credentials and permissions and is tailored for my role. An Engineering manager will have access to a different set of data and tools than a manager. So does the needs and how the agent reacts to queries.

When I discovered Amazon Bedrock AgentCore I realised I could build exactly what I needed: a hierarchical multi-agent system where specialized AI workers handle different domains while an orchestrator coordinates them. SideKick AI was born from this real pain point and the exciting potential of AWS's newest AI services.

What it does

In short Sidekick is designed to be the goto tool which helps you find what needs your attention, help find the supplementary information to get it done, brainstorm and refine and delegate where possible.

How we built it

This is an effort of two week using Kiro. The primary goal was to test AWS services readiness.

Challenges we ran into

The biggest challenge is user based authorisation. The differentiating factor of this project from others is that it will rely on user's access instead of service users or global tokens. This is particularly tricky and although AgentCore identity aims to solve it, we couldn't manage to use it fully in the short duration.

We ran into this particular issue while trying to use Atlassian MCP. As a workaround Atlassian API was used for the demo.

Accomplishments that we're proud of

Achieving this level of autonomy in a software in two weeks time is incredible. The agent's work relatively well with very little tweaking. I would like to highlight a few technical accomplishments.

Flexibility of the Architecture

The orchestrator Agent makes it really easy to plug in more functionality. Adding more agents is extremely easy. Having a layer of worker agents that can be shared with domain specialist agents, create a really nice hierarchal setup that can handle a lot of use cases. The system can handle complexity and yet it can be secure by adding Gurdrails both in agent prompts and LLM.

Cost effective

Hosting the system in ECS fargate and the agents in AgentCore are really cost effective. There are minimal idle costs and the system pricing is mostly based on the usage.

Moreover using NovaPro for complex agents like orchestrator and NovaLite for simpler agents really cuts down the cost.

What we learned

We can iterate quickly using Tools as Agents architecture. Hosting everything in a single runtime really helps iterate rapidly. The tooling provided by AgentCore is more than enough to create mature Agentic services. StrandsAgents is a powerful and easy to use framework. The integrations of AgentCore with rest of the AWS services like cloudwatch is neatly integrated.

What's next for Sidekick

• Replace the static data with actual integrations.
• Use remote MCPs instead of APIs. This will require extensive use of AgentCore Identity services.
• Memory and Multi-tenancy so the system is better personalised.
• Add more agents particularly an Agent for presentation.
• Add a UI layer to create agents easily.
• Slack Integration

Built With

• agentcore
• amazon-web-services
• bedrock
• ecs
• strandsagents
• streamlit