Weekend Deployment Challenge: Second Eyes #AgentsForHumans
Second Eyes started with a very ordinary creative-production problem: a publishing team has hundreds of photographs, a deadline is approaching, and the final editorial choice still belongs to a human. For this challenge, what I deployed is a static presentation layer running on AWS Amplify Hosting.
Weekend Deployment Challenge: Second Eyes
#deployment
What My App Does
Second Eyes started with a very ordinary creative-production problem: a publishing team has hundreds of photographs, a deadline is approaching, and the final editorial choice still belongs to a human.
The product idea is simple:
Most things stay filed. Questions come to you.
Instead of asking AI to rank photographs by taste or automatically choose the “best” image, Second Eyes is designed around a different division of labor. Routine cases stay out of the way, while ambiguity, conflicting evidence, and missing information are brought forward for human judgment.
For the Weekend Deployment Challenge, I deployed the static presentation layer of Second Eyes.
The deployed Publishing Workroom shows a 400-photo editorial scenario divided into three areas:
- SHORTLIST — 18
- NEEDS REVIEW — 7
- REMAINING — 375
The interface is deliberately designed like an editorial workroom rather than an AI dashboard. The point is to show what the workflow should feel like from the user's perspective: most material remains filed, while a small number of questions arrive at the editor's desk.
One important boundary: these counts and placements are illustrative presentation content. This AWS deployment does not run the Second Eyes model pipeline, process 400 original images, or invoke Gemini, Amazon Nova, Amazon Bedrock, or AgentCore.
For this challenge, what I deployed is exactly what I claim: a static presentation layer running on AWS Amplify Hosting.
How I Built It
The presentation consists of two static HTML pages, one CSS file, and 12 compressed derivative images.
There are two states:
- a publishing brief is established;
- a publishing brief is missing.
The pages link to each other so the user can see how the product changes when the system has — or does not have — a valid basis for making a comparison.
I intentionally kept the deployment process extremely small.
Rather than connect the repository to a continuous deployment pipeline, I packaged the static site into a ZIP archive and manually deployed it to AWS Amplify Hosting in
us-east-1.The Amplify deployment completed successfully, HTTPS was available automatically, and I verified both pages, the stylesheet, all 12 images, and the navigation between the two states.
I also verified that the original GitHub Pages version continued to work. That means the Amplify version could function as a challenge-specific deployed mirror without disturbing the existing public project.
This turned out to be a useful constraint.
Instead of using deployment as an excuse to expand the product, I treated deployment as its own engineering task: take one finished surface, freeze it, ship exactly those bytes, and verify that the public version behaves the same way.
AWS Services Used / Architecture Overview
For this deployment, I used one AWS service:
AWS Amplify Hosting
The architecture is intentionally minimal:
1
2
3
4
5
6
7
8
9
10
11
Static HTML + CSS + 12 image derivatives
|
v
ZIP deployment
|
v
AWS Amplify Hosting
(us-east-1)
|
v
Public HTTPS website
There is no backend attached to this deployment.
The deployed site does not call the Second Eyes agent runtime and has no access to Gemini, Nova, Bedrock, AgentCore, Batch A, or the original 400-photo source corpus.
Deployment permissions were also intentionally limited to what was required for static Amplify deployment. Runtime permissions were not opened.
I had previously experimented with an Amazon Bedrock / Nova path in the broader Second Eyes project, but available daily model quota prevented me from claiming successful Nova inference evidence. I kept that boundary intact here rather than quietly substituting deployment for runtime capability.
For this weekend challenge, Amplify Hosting is the AWS service actually used by the live app.
What I Learned
The useful lesson was surprisingly mundane:
deployment does not have to be the same thing as integration.
I normally think about deployment as part of a larger automated pipeline: repository connection, builds, runtime services, APIs, permissions, and continuous updates.
For this project, manual ZIP deployment was actually the better choice.
The presentation layer was already frozen and validated. Connecting GitHub and adding a build pipeline would have introduced new moving parts without improving the artifact I wanted to publish.
Manual deployment gave me a clean separation:
prototype first → freeze the artifact → deploy it → verify it → add runtime later
It also reinforced a principle I have been learning throughout Second Eyes: systems earn trust through boundaries.
A static interface should not pretend to be a live inference system simply because both can be placed behind the same URL.
Shipping something smaller — but real — was more valuable than turning the deployment challenge into another architecture project.
The next step is to deploy the controlled Second Eyes runtime separately, connect real runtime records to the interface, and only then replace illustrative placements with actual generated evidence.
For this weekend, however, the goal was simpler:
get something real onto AWS and make sure it works.
Done.
Links
Live AWS Amplify deployment:
https://main.dvx4tmt6s6hty.amplifyapp.com
Public GitHub repository:
https://github.com/Crystal32378/second-eyes-agent
https://github.com/Crystal32378/second-eyes-agent
Second Eyes demo video:
https://www.youtube.com/watch?v=uSYH90j3dls
https://www.youtube.com/watch?v=uSYH90j3dls
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article