How it works
web · app/main.pyThe only process with memory. It keeps two lists, tasks and jobs, serves this page, and answers a small HTTP API. Everything else is a client of it. Restart it and the lists are gone: that is deliberate at this step.
worker · app/worker.pyA plain Python loop, no port. Every few seconds: send a heartbeat, ask the web process for the next queued job, do it, report the result. Two copies run here; on AWS the number of copies is a setting.
ticker · app/ticker.pyA scheduled task. It wakes up, counts the jobs, posts a one-line report as its heartbeat, and exits. Here it loops every 30 seconds; on AWS a schedule starts a fresh one every few minutes.
agent · app/agent.pyOn AWS it runs on AgentCore Runtime as its own process (app/agentcore.py); on a laptop it runs inside the web process. A LangGraph loop over DeepSeek on OpenRouter: ask the model, run the tool it asks for, give it the result, repeat. Its tools: read the lists above, submit jobs, search Wikipedia, and ask DeepWiki about GitHub repositories over MCP.
How they talk. Plain HTTP to the web process, nothing else: POST /api/heartbeat "I am here", POST /api/jobs/claim "give me a job", POST /api/jobs/{id}/result "here is the outcome". The queue is a list in the web process handed out first come, first served. No message queue, no database, no Redis, yet.
The agent's tools. Ours, in app/agent.py: list_tasks, list_jobs, job_status, submit_job, search_wikipedia, wikipedia_summary. From the DeepWiki MCP server: ask_question, read_wiki_structure, read_wiki_contents, which know GitHub repositories, not people.
Try this. Submit five count_primes jobs and watch both workers turn busy while the rest wait in the queue. Stop one worker and watch its dot turn red while the other keeps going. Ask the agent "how long is the queue?"
Next steps · one commit each
1 · the applicationFour processes on one laptop, talking over HTTP to the web process. State in memory. Key in a .env file.
2 · containersOne Dockerfile, one image. docker compose up runs the same four processes as containers. Same image everywhere from now on.
3 · continuous integrationGitHub Actions: lint and tests on every push; on main, build the image and publish it to GitHub's registry, tagged with the commit.
4 · infrastructure as codeOne CDK stack: a network, an ECS cluster, the web as an Express service behind a load balancer, the workers as a service with a CPU autoscaling policy, the ticker as a scheduled task, and the key read from Secrets Manager. Deployed once by hand.
5 · continuous deploymentA second stack, deployed once by hand: an ECR repository and a role GitHub may assume with no stored key. The pipeline pushes the image there and runs cdk deploy with its tag on every merge to main. This page is served from ECS. This page goes live at an HTTPS URL, showing real tasks.
6 · the agent on AgentCore ← you are hereThe agent moves out of the web process onto AgentCore Runtime, the same image with a different command, and reaches its MCP tools through an AgentCore Gateway that only lets its IAM role in. The chat box now talks to it through the web process.